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Preface 



UML est le resultat d'un long processus initialise depuis maintenant deux ans par 
trois des methodologistes les plus reputes : Grady Booch, Ivar Jacobson et Jim 
Rumbaugh. Conscients que leurs travaux respectifs ne representaient que les 
diverses facettes d'un meme probleme, ils ont eu l'intelligence de joindre leurs 
efforts plutot que de se lancer dans d'inutiles querelles de chapelles. Deux ans de 
travail au sein de Rational Software Corporation, soutenus dans leurs efforts par 
de nombreux autres specialistes du domaine, leur ont permis de definir cette 
nouvelle approche de la modelisation des logiciels a base d'objets. UML est a la 
fois la synthese et le successeur naturel de leurs differents travaux. De par sa 
standardisation par l'OMG, qui devrait aboutir dans le courant de l'annee 1997, et 
de par son adoption par les plus grands acteurs du monde de l'informatique : 
IBM, Microsoft, Oracle, Hewlett Packard, pour ne citer que les plus grands, UML 
est appele a devenir a tres court terme le standard pour la modelisation des 
applications informatiques de demain. 

Pierre Alain Muller, pour avoir passe cinq ans a Rational Software en contact 
direct avec les gourous du domaine, etait la personne la plus a meme de rediger ce 
premier ouvrage en francais sur UML. Ses competences indiscutables dans le 
domaine, alliees a son sens profond de la pedagogie, font de cet ouvrage un 
guide indispensable a tous ceux qui veulent comprendre et appliquer les principes 
d'UML dans le developpement de leurs applications. 

Etienne Morel 
Directeur General 
Rational Software Europe 
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A qui s'adresse ce livre 



Ce livre traite de modelisation objet. II decrit la mise en oeuvre de la notation UML 
(Unified Modeling Language), developpee en reponse a l'appel a propositions 
lance par l'OMG (Object Management Group), dans le but de definir la notation 
standard pour la modelisation des applications construites a l'aide d'objets. 

La notation UML represente l'etat de l'art des langages de modelisation objet. 
Elle se place comme le successeur naturel des notations des methodes de Booch, 
OMT (Object Modeling Technique) et OOSE (Object Oriented Software 
Engineering) et, de ce fait, UML s'est tres rapidement imposee, a la fois aupres 
des utilisateurs et sur le terrain de la normalisation. 

Ce livre s'adresse a tous ceux qui desirent comprendre et mettre en oeuvre 
l'approche objet, et plus particulierement aux professionnels de l'informatique qui 
doivent aborder la transition vers UML. La lecture de l'ouvrage ne demande pas 
de connaissances prealables en technologie objet, mais suppose des 
connaissances informatiques de base. Le livre peut servir d'accompagnement a un 
cours de second cycle ou d'annee de specialisation d'ecole d'ingenieur. 

Le contenu de ce livre, le cheminement propose et le niveau d' abstraction retenu 
dans la presentation de la notation UML, sont le fruit d'une pratique des 
methodes objet, dans des projets reels. La redaction insiste tout particulierement 
sur la modelisation objet, c'est-a-dire sur l'analyse et la definition des besoins de 
l'utilisateur ; ceci non pas, parce que la conception ou la programmation seraient 
des taches moins nobles, mais tout simplement, parce que les informaticiens ont 
beaucoup plus de mal a trouver ce qu'il faut faire, qu'a trouver comment le faire. 

L'ouvrage est divise en 5 chapitres qui peuvent etre lus de maniere quasi 
independante : 
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• le premier chapitre met en avant le besoin de methodes et decrit la genese de 
la notation unifiee UML, 

• le deuxieme chapitre presente les concepts de base de la technologie objet, 
afin de rendre la lecture de l'ouvrage accessible aux neophytes, 

• le troisieme chapitre decrit les concepts d'UML, en utilisant la notation comme 
support pour la description de la semantique des elements de modelisation, 

• le quatrieme chapitre introduit les bases de l'encadrement des projets objet, 
avec une description du processus de developpement sous-tendu par UML 
(pilote par les use cases, centre sur 1' architecture, iteratif et incremental), 

• le cinquieme chapitre presente une etude de cas : la modelisation objet avec 
UML d'un systeme de controle des acces a un batiment. 

Le livre se termine par des annexes sur la transition vers UML et sur des regies de 
mise en oeuvre, organisees de la maniere suivante : 

• un guide de transition de Booch et OMT vers UML, 

• la generation de code C++, 

• la generation de code Java, 

• la generation de code IDL, 

• la generation de code Visual Basic, 

• la generation de code SQL. 

Plusieurs lectures de l'ouvrage sont possibles, selon les connaissances et les 
centres d'interets du lecteur: 

• Le lecteur novice est invite a lire l'ensemble du livre, en suivant l'ordre des 
chapitres. Ce conseil s'applique egalement aux programmeurs qui ont acquis 
une connaissance d'un langage de programmation objet comme C++, sans 
avoir suivi de formation specifique a 1' analyse et a la conception objet. 

• Le lecteur qui possede deja une bonne connaissance d'une methode de 
modelisation, telle que Booch ou OMT, pourra entamer la lecture a partir du 
troisieme chapitre. II lui est par contre recommande de parcourir egalement le 
deuxieme chapitre, car l'experience montre que certains concepts comme celui 
de generalisation sont souvent mal compris. 

• Les architectes du logiciel, apres avoir etudie la notation UML dans le 
troisieme chapitre, se concentreront tout particulierement sur le quatrieme 
chapitre qui traite d' architecture objet et presente le modele des 4+1 vues. 

• Les chefs de projets trouveront egalement dans le quatrieme chapitre les 
informations necessaires pour la mise en place d'un processus de 
developpement pilote par les cas d'utilisation (use cases), centre sur 
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l'architecture, iteratif et incremental. II leur sera aussi profitable de parcourir les 
premiers chapitres, afin de pouvoir lire et comprendre les modeles. 

II est probablement utile de dire aussi que ce livre n'est : 

• ni un traite de programmation objet ; il ne decrit aucun langage de 
programmation en detail, 

• ni une apologie d'UML ; mais plutot un ouvrage de modelisation objet, qui 
faut appel a la notation UML. 



1 

La genese d'UML 



L'informatique s'est glissee imperceptiblement dans notre vie quotidienne. Des 
machines a laver aux lecteurs de disques compacts, en passant par les 
distributeurs de billets et les telephones, quasiment toutes nos activites 
quotidiennes utilisent du logiciel et, plus le temps passe, plus ce logiciel devient 
complexe et couteux. 

La demande de logiciels sophistiques alourdit considerablement les contraintes 
imposees aux equipes de developpement. Le futur des informaticiens s'annonce 
comme un monde de complexite croissante, a la fois du fait de la nature des 
applications, des environnements distribues et heterogenes, de la taille des 
logiciels, de la composition des equipes de developpement, et des attentes 
ergonomiques des utilisateurs. 

Pour surmonter ces difficultes, les informaticiens vont devoir apprendre a faire, a 
expliquer, et a comprendre. C'est pour ces raisons qu'ils ont et auront toujours 
plus besoin de methodes. Le temps de l'informatique intuitive et des programmes 
qui tombent en marche s'acheve. Place au doux reve de l'informatique adulte, 
raisonnee, efficace ! 



Les methodes d'analyse et de conception 



A quoi sert une methode ? 

Une methode definit une demarche reproductible pour obtenir des resultats 
fiables. Tous les domaines de la connaissance utilisent des methodes plus ou 
moins sophistiquees et plus ou moins formalisees. Les cuisiniers parlent de 
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recettes de cuisine, les pilotes deroulent des check-lists avant le decollage, les 
architectes dessinent des plans et les musiciens suivent des regies de 
composition. 

De meme, une methode d' elaboration de logiciels decrit comment modeliser et 
construire des systemes logiciels de maniere fiable et reproductible. 

De maniere generale, les methodes permettent de construire des modeles a partir 
d'elements de modelisation qui constituent des concepts fondamentaux pour la 
representation de systemes ou de phenomenes. Les notes reportees sur les 
partitions sont des elements de modelisation pour la musique. L'approche objet 
propose l'equivalent des notes - ce sont les objets - pour la representation des 
logiciels. 

Les methodes definissent egalement une representation - souvent graphique - 
qui permet d'une part de manipuler aisement les modeles, et d'autre part de 
communiquer et d'echanger l'information entre les differents intervenants. Une 
bonne representation recherche l'equilibre entre la densite d' information et la 
lisibilite. 

En plus des elements de modelisation et de leurs representations graphiques, une 
methode definit des regies de mise en oeuvre qui decrivent l'articulation des 
differents points de vue, l'enchainement des actions, l'ordonnancement des 
taches et la repartition des responsabilites. Ces regies definissent un processus 
qui assure 1'harmonie au sein d'un ensemble d'elements cooperatifs et qui 
explique comment il convient de se servir de la methode. 

Avec le temps, les utilisateurs d'une methode developpent un savoir-faire lie a sa 
mise en ceuvre. Ce savoir-faire, egalement appele experience, n'est pas toujours 
formule clairement, ni aisement transmissible. 

Des methodes fonctionnelles aux methodes objet 

Les methodes structurees et fonctionnelles se sont imposees les premieres, bien 
que les methodes objet aient leurs racines solidement ancrees dans les annees 60. 
Ce n'est guere surprenant, car les methodes fonctionnelles s'inspirent 
directement de l'architecture des ordinateurs, c'est-a-dire d'un domaine eprouve 
et bien connu des informaticiens. La separation entre les donnees et le code, telle 
qu'elle existe physiquement dans le materiel, a ete transposee vers les methodes ; 
c'est ainsi que les informaticiens ont pris l'habitude de raisonner en termes de 
fonctions du systeme. Cette demarche est naturelle lorsqu'elle est replacee dans 
son contexte historique ; aujourd'hui, de part son manque d' abstraction, elle est 
devenue quasiment anachronique. II n'y a en effet aucune raison d'inscrire des 
reponses materielles dans des solutions logicielles. Le logiciel s'execute sur du 
materiel qui doit etre a son service et non sur du materiel qui lui impose des 
contraintes d' architecture. 
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Plus recemment, vers le debut des annees 80, les methodes objet ont commence a 
emerger. L'Histoire - avec un grand H - est un eternel recommencement. La petite 
histoire des methodes se repete elle aussi. Le cheminement des methodes 
fonctionnelles et des methodes objet est similaire. Au debut existait la 
programmation, avec dans un cas le sous-programme et dans l'autre, l'objet 
comme element structurant de base. Quelques annees plus tard, les informaticiens 
poussent le concept structurant vers la conception et inventent la conception 
structured dans un cas et la conception objet dans l'autre. Plus tard encore, la 
progression vers l'analyse est operee, toujours en exploitant le meme paradigme, 
soit fonctionnel, soit objet. Chaque approche peut done proposer une demarche 
complete, sur 1' ensemble du cycle de vie du logiciel. 



Programmation 




Conceptior 





Analyse 



Evo utior ess methodes 



Figure 1 : L' evolution des methodes, objet ou non, s'est toujours faite de la programmation 

vers l'analyse. 

Dans les faits, la situation est legerement plus complexe. En effet, souvent les 
methodes ne couvrent pas 1' ensemble du cycle de vie. Cela se traduit alors par la 
juxtaposition de methodes : une methode A pour l'analyse, suivie d'une methode 
C pour la conception. Cette approche parcellaire, tant qu'elle est confinee dans un 
des paradigmes - 1' approche fonctionnelle ou 1' approche objet - reste 
raisonnable. En revanche, le melange de paradigmes est nettement moins 
raisonnable, bien que comprehensible. Vers le milieu des annees 80, les bienfaits 
de la programmation objet commencent a etre largement reconnus, et la 
conception objet semble une approche raisonnable pour qui veut mettre en oeuvre 
un langage de programmation objet comme Smalltalk. Du cote de l'analyse par 
contre, la notion d' analyse objet n'est que vapeur et supputation. Les entreprises 
ont developpe a cette epoque une solide connaissance des methodes d' analyse 
fonctionnelle et de modelisation semantique des donnees ; les informaticiens 
s'emploient done tout naturellement a juxtaposer une phase de conception objet a 
une phase d' analyse fonctionnelle. Cette maniere de proceder presente de 
nombreux inconvenients lies au changement de paradigme. Le passage de 
l'analyse fonctionnelle a la conception objet necessite une traduction des 
elements de modelisation fonctionnelle vers les elements de modelisation objet, 
ce qui est loin d'etre commode et naturel. En effet, il n'y a pas de bijection entre 
les deux ensembles, de sorte qu'il faut casser les elements de modelisation d'une 
des approches pour construire des fragment d'elements de modelisation de 
l'autre approche. Le resultat net de ce changement d'etat d'esprit en cours de 
developpement est de limiter considerablement la navigation entre l'enonce des 
besoins en amont de l'analyse et la satisfaction de ces besoins en aval de la 
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conception. D' autre part, une conception objet obtenue apres traduction manque 
tres souvent d'abstraction et se limite a 1' encapsulation des objets de bas 
niveaux, disponibles dans les environnements de realisation et d' execution. Tout 
ceci implique beaucoup d' efforts pour des resultats somme toute bien peu 
satisfaisants. 




Figure 2 : La combinaison d'une approche fonctionnelle pour I'analyse et d'une approche 
objet pour la conception et la realisation n'a plus lieu d'etre aujourd'hui car les methodes 
objet actuelles couvrent V ensemble du cycle de vie du logiciel. 

Durant la derniere decennie, des applications objet - depuis I'analyse des 
besoins, jusqu'a la realisation - ont ete developpees dans tous les secteurs 
d' applications. L'experience acquise sur ces projets permet de savoir comment 
enchainer les differentes activites selon une approche totalement objet. A ce jour, 
revolution des pratiques n'est pas totale et des adeptes de la mixite existent 
toujours, prisonniers du poids de leurs habitudes. Les organisations qui sont sur 
le point de faire la transition vers l'objet ne doivent pas reproduire ce travers. II 
est bien plus simple de mettre en oeuvre une approche totalement objet, cela 
d'autant plus que les logiciels developpes de cette facon sont plus simples, plus 
robustes et mieux adaptes aux attentes de leurs utilisateurs. 

La proliferation des methodes objet 

La premiere moitie des annees 90 a vu fleurir une cinquantaine de methodes objet. 
Cette proliferation est le signe de la grande vitalite de l'objet, mais aussi le fruit 
d'une multitude d' interpretations de ce qui est objet, de ce qui Test moins et de ce 
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qui ne Test pas du tout 1 . Le travers de cette effervescence methodologique est 
d'encourager la confusion, de sorte que les utilisateurs se placent dans une 
situation d'attentisme qui limite les progres des methodes. La meilleure validation 
reste la mise en oeuvre ; les methodes ne sont pas figees, elles evoluent en 
reponse aux commentaires des utilisateurs. 

Fort heureusement, l'examen des methodes dominantes permet de degager un 
consensus autour d'idees communes. Les grands traits des objets, repris par de 
nombreuses methodes, s'articulent autour des notions de classe, d'association 
(decrite par James Rumbaugh), de partition en sous-systemes (Grady Booch) et 
autour de l'expression des besoins a partir de l'etude de l'interaction entre 
l'utilisateur et le systeme (les use cases d'lvar Jacobson). 

Enfin, les methodes bien implantees - comme celles de Booch et OMT {Object 
Modeling Technique)- se sont renforcees par l'experience, en adoptant les 
elements methodologiques les plus apprecies par les utilisateurs. 

Rapprochement de Booch et OMT 

Les deuxiemes moutures des methodes de Booch et OMT, appelees 
respectivement Booch'93 et OMT-2, se sont rapprochees tant et si bien qu'elles 
sont devenues plus ressemblantes que differentes. Les variations subsistantes 
sont minimes et concentrees principalement dans la terminologie et dans la 
notation. 

Booch'93 s'inspire d'OMT et adopte les associations, les diagrammes de Harel 2 , 
les traces d'evenements, etc. 

OMT-2 s'inspire de Booch et introduit les flots de message, les modeles 
hierarchiques et les sous-systemes, les composants modeles, et surtout, retire du 
modele fonctionnel les diagrammes de flot de donnees, herites d'un passe 
fonctionnel et peu integres avec la forme general e d'OMT. 

A ce stade, les deux methodes offrent une couverture complete du cycle de vie, 
avec toutefois une difference notable dans l'eclairage. Booch-93 insiste plus sur 
la construction alors qu'OMT-2 se concentre sur 1' analyse et 1' abstraction. 
Neanmoins, il n'existe entre les deux methodes aucune incompatibilite majeure. 

Les concepts objet ont souvent une histoire compliquee et imbriquee. Les 
elements presentes dans le tableau suivant se sont degages de l'experience de 



1 Amghar Y. & al. 25-27 octobre 1995, Domaines et utilisation de la technologie a 
objets. Congres AFCET'95, Toulouse, pp. 43-72. 

2 Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science 
of Computer Programming vol. 8. 
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mise en oeuvre des differentes methodes et ont marque l'effort d'unification des 
methodes de Booch et OMT. 



Origine 


Element 


Booch 


Categories et sous-systemes 


Embley 


Classes singletons et objets composites 


Fusion 


Description des operations, numerotation des messages 


Gamma et al. 


Frameworks, patterns et notes 


Harel 


Automates (Statecharts) 


Jacobson 


Cas d'utilisation (use cases) 


Meyer 


Pre- et post-conditions 


Odell 


Classification dynamique, eclairage sur les evenements 


OMT 


Associations 


Shlaer-Mellor 


Cycle de vie des objets 


Wirfs-Brock 


Responsabilites (CRC) 



Figure 3 : Principaux elements empruntes par Booch'93 et OMT-2 aux differentes methodes 

objet. 



L'unification des methodes 



Vers un langage unifie pour la modelisation 

L'unification des methodes de modelisation objet est rendue possible parce que 
l'experience a permis de faire le tri entre les differents concepts proposes par les 
methodes existantes. 

Partant de la constatation que les differences entre les methodes s'amenuisent et 
que la guerre des methodes ne fait plus progresser la technologie objet, Jim 
Rumbaugh et Grady Booch decident fin 94 d'unifier leurs travaux au sein d'une 
methode unique : la methode unifiee (The Unified Method). Une annee plus tard, 
ils sont rejoints par Ivar Jacobson, le createur des cas d'utilisation (use cases), 
une technique tres efficace pour la determination des besoins. 

Booch, Jacobson et Rumbaugh se fixent quatre objectifs : 

• representer des systemes entiers (au-dela du seul logiciel) par des concepts 
objets, 
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• etablir un couplage explicite entre les concepts et les artefacts executables, 

• prendre en compte les facteurs d'echelle inherents aux systemes complexes et 
critiques, 

• creer un langage de modelisation utilisable a la fois par les humains et les 
machines. 

Les auteurs de la methode unifiee atteignent tres rapidement un consensus sur 
les concepts fondamentaux de l'objet. En revanche, la convergence sur les 
elements de notation est plus difficile a obtenir et la representation graphique 
retenue pour les differents elements de modelisation connaitra plusieurs 
modifications. 

La premiere version de la description de la methode unifiee a ete presentee en 
octobre 1995, dans un document intitule Unified Method V0.8. Ce document a ete 
largement diffuse et les auteurs ont recueilli plus d'un millier de commentaires 
detailles de la part de la communaute des utilisateurs. Ces commentaires ont ete 
pris en compte dans la version 0.9 parue en juin 1996, mais c'est surtout la version 
0.91, disponible depuis octobre 1996, qui permet de noter revolution de la 
methode unifiee. 

La principale modification consiste en la reorientation de la portee de 1' effort 
d' unification, d'abord vers la definition d'un langage universel pour la 
modelisation objet, et eventuellement ensuite vers la standardisation du 
processus de developpement objet. La methode unifiee %Jnified Method) se 
transforme en UML (The Unified Modeling Language for Object-Oriented 
Development). 

En 1996, il apparait clairement qu'UML est percue comme un element de base 
dans la strategie de plusieurs grandes entreprises. C'est ainsi que se cree un 
consortium de partenaires pour travailler a la definition de la version 1.0 d'UML ; 
il regroupe notamment : DEC, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI 
Systemhouse, Microsoft, Oracle, Rational Software, TI et Unisys. 

De cette collaboration nait la description d'UML version 1.0 remise a l'OMG le 17 
janvier 1997, en vue de sa standardisation durant l'annee 1997. 
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Standardisation par I'DMG 



/ 



Sou m ission a I' OMG - ja ivier 97 UML 1 . 0 
Version beta OOPSLA'96 
WWW-juin96 



OOPSLA'95 
Comments ires 




T'ois livr&s a venir : 
Guide dc I'utilisateur 
Manuel dc roTc-rancc 
Guide du processus 



Specification d sponiblc 
sur Internet 



Specification d sponible 
sur Internet 



Jeu de documentation 



AuTes me:hodes 



Eooch'91 



OMT 1 



OOSE Partenaires 



Figure 4 : Principales etapes de la definition d'UML. 

Les createurs d'UML insistent tout particulierement sur le fait que la notation 
UML est un langage de modelisation objet et non pas une methode objet. Les 
commentaires recueillis en reponse a la publication de la version 0.8 ont 
clairement montre que les utilisateurs attendaient une formalisation des artefacts 
du developpement, plutot que du processus d'elaboration de ces artefacts. En 
consequence, la notation UML a ete confue pour servir de langage de 
modelisation objet, independamment de la methode mise en oeuvre. La notation 
UML peut ainsi se substituer - sans perte d'information - aux notations des 
methodes de Booch, OMT ou encore OOSE {Object Oriented Software 
Engineering egalement appelee Objectory). 

UML n'est pas une notation proprietaire : elle est accessible a tous et les 
fabricants d'outils ainsi que les entreprises de formation peuvent librement en 
faire usage. La volonte d'ouverture, la richesse de la notation et la definition 
semantique precise des elements de modelisation font d'UML une notation 
generale et simple, sans etre simpliste. 

En francais, UML pourrait se traduire par langage unifie pour la modelisation 
objet, mais il est plus que probable qu'UML se traduise plutot par notation 
unifiee, voire notation UML, sur le meme schema que methode OMT. 



Modele et metamodele 

L'effort initial porte sur 1' identification et la definition de la semantique des 
concepts fondamentaux qui forment les briques de base de la modelisation objet. 
Ces concepts constituent les artefacts du developpement et ils doivent pouvoir 
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etre echanges entre les differents intervenants des projets. Pour realiser ces 
echanges, il faut d'abord s'accorder sur l'importance relative de chaque concept, 
etudier les consequences de ces choix et choisir une representation graphique 
dont la syntaxe soit a la fois simple, intuitive et expressive. 

Pour faciliter ce travail de definition et pour formaliser UML, tous les differents 
concepts ont ete eux-memes modelises avec UML. Cette definition recursive, 
appelee metamodelisation, presente le double avantage de permettre de classer 
les concepts par niveau d' abstraction, de complexite et de domaine d' application, 
et aussi de faire la preuve de la puissance d'expression de la notation, capable 
entre autres de se representer elle-meme. 

Un metamodele decrit de maniere formelle les elements de modelisation et la 
syntaxe et la semantique de la notation qui permet de les manipuler. Le gain 
d'abstraction induit par la construction d'un metamodele facilite 1' identification 
d'eventuelles incoherences et encourage la genericite. Le metamodele d'UML sert 
de description de reference pour la construction d'outils et pour le partage de 
modeles entre outils differents. 

Un modele est une description abstraite d'un systeme ou d'un processus, une 
representation simplifiee qui permet de comprendre et de simuler. Le terme 
modelisation est souvent employe comme synonyme d' analyse, c'est-a-dire de 
decomposition en elements simples, plus faciles a comprendre. En informatique, la 
modelisation consiste tout d'abord a decrire un probleme, puis a decrire la 
solution de ce probleme ; ces activites s'appellent respectivement 1' analyse et la 
conception. 

La forme du modele depend du metamodele. La modelisation fonctionnelle 
decompose les taches en fonctions plus simples a realiser. La modelisation objet 
decompose les systemes en objets collaborants. Chaque metamodele definit des 
elements de modelisation et des regies pour la composition de ces elements de 
modelisation. 

Le contenu du modele depend du probleme. Un langage de modelisation comme 
UML est suffisamment general pour etre employe dans tous les domaines 
informatiques et meme au-dela, par exemple pour l'ingenierie des affaires. 

Un modele est l'unite de base du developpement ; il est fortement coherent avec 
lui-meme et faiblement couple avec les autres modeles par des liens de navigation. 
En regie generale, un modele est relie a une phase precise du developpement et 
est construit a partir d'elements de modelisation avec leurs differentes vues 
associees. 

Un modele n'est pas directement visible par les utilisateurs. II capture la 
semantique sous-jacente d'un probleme et contient des donnees exploitees par 
les outils pour l'echange d' information, la generation de code, la navigation, etc. 

UML definit plusieurs modeles pour la representation des systemes : 
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• le modele des classes qui capture la structure statique, 

• le modele des etats qui exprime le comportement dynamique des objets, 

• le modele des cas d'utilisation qui decrit les besoins de l'utilisateur, 

• le modele d' interaction qui represente les scenarios et les flots de messages, 

• le modele de realisation qui montre les unites de travail, 

• Le modele de deploiement qui precise la repartition des processus. 

Les modeles sont regardes et manipules par les utilisateurs au moyen de vues 
graphiques, veritables projections au travers des elements de modelisation 
contenus par un ou plusieurs modeles. De nombreuses vues peuvent etre 
construites a partir des modeles de base ; elles peuvent montrer tout ou partie des 
modeles. A chaque vue correspondent un ou plusieurs diagrammes. UML definit 
neuf types de diagrammes differents : 

• les diagrammes de classes, 

• les diagrammes de sequence, 

• les diagrammes de collaboration, 

• les diagrammes d' objets, 

• les diagrammes d'etats-transitions, 

• les diagrammes d'activites, 

• les diagrammes de cas d'utilisation, 

• les diagrammes de composants, 

• les diagrammes de deploiement. 

Des notations differentes peuvent etre des vues du meme modele. Les notations 
de Booch, OMT et OOSE utilisent des syntaxes graphiques differentes, mais 
represented les memes concepts objet. Ces notations graphiques differentes ne 
sont en fait que des vues differentes des memes elements de modelisation, de 
sorte qu'il est tout a fait possible d'utiliser differentes notations sans perdre le 
contenu semantique. UML n'est qu'une autre representation graphique d'un 
modele semantique commun. 



2 

L'approche objet 



Ce chapitre presente les concepts de base de l'approche objet. II s'adresse tout 
particulierement aux informaticiens qui s'orientent vers l'objet. La maitrise des 
notions presentees dans ce chapitre est essentielle pour une bonne lecture de la 
suite de l'ouvrage. Les exemples presentes introduisent graduellement quelques 
bases de la notation UML. 



Pourquoi l'approche objet ? 



Quelle est la raison qui rend l'approche objet tellement attractive ? A cette 
question, les adeptes de l'objet repondent invariablement que les avantages de 
l'approche objet sont la stabilite de la modelisation par rapport aux entites du 
monde reel, la construction iterative facilitee par le couplage faible entre 
composants et la possibilite de reutiliser des elements d'un developpement a un 
autre. Certains insistent egalement sur la simplicite du modele qui ne fait appel 
qu'a cinq concepts fondateurs (les objets, les messages, les classes, l'heritage et 
le polymorphisme) pour exprimer de maniere uniforme 1' analyse, la conception et 
la realisation d'une application informatique. Tous ces points sont parfaitement 
exacts, mais ils ne sont que la consequence de la fantastique capacite 
d' integration - d' unification - de l'approche objet. 

D'une maniere generale, toute methode de construction de logiciels doit prendre 
en compte l'organisation, la mise en relation et l'articulation de structures pour en 
faire emerger un comportement macroscopique complexe : le systeme a realiser. 
L'etude du systeme doit done necessairement prendre en consideration 
l'agencement collectif des parties, et conduire a une vue plus globale des 
elements qui le composent. Elle doit progresser a differents niveaux d'abstraction 



16 - Modelisation objet avec UML 



et, par effet de zoom, s'interesser aussi bien aux details qu'a l'ordonnancement de 
l'ensemble. 

La construction d'un logiciel est par consequent une suite d'iterations du genre 
division-reunion ; il faut decomposer - diviser - pour comprendre et il faut 
composer - reunir - pour construire. Ceci conduit a une situation paradoxale : il 
faut diviser pour reunir ! 

Face a ce paradoxe, le processus de decomposition a ete dirige traditionnellement 
par un critere fonctionnel. Les fonctions du systeme sont identifiees, puis 
decomposees en sous-fonctions, et cela recursivement jusqu'a l'obtention 
d'elements simples, directement representables dans les langages de 
programmation (par les fonctions et les procedures). 



Fcnclion pr nriaale 



Sous-forction 1 



Sous-fo nction 2 



Sous-fonstion ' 1 SciuS'fQric-iiEn 1 ? Scus-fonction 2.1 5-Diis-fonction 2.2 



Figure 5 : Decomposition fonctionnelle et hierarchique. 



L' architecture du logiciel ainsi realise est le reflet des fonctions du systeme. Cette 
demarche, dont les mecanismes integrateurs sont la fonction et la hierarchie, 
apporte des resultats satisfaisants lorsque les fonctions sont bien identifiees et 
lorsqu'elles sont stables dans le temps. Toutefois, etant donne que la fonction 
induit la structure, les evolutions fonctionnelles peuvent impliquer des 
modifications structurelles lourdes, du fait du couplage statique entre architecture 
et fonctions. 

L'approche objet repose a la fois sur le rationalisme d'une demarche cartesienne et 
sur une demarche systemique qui considere un systeme comme une totalite 
organisee, dont les elements solidaires ne peuvent etre definis que les uns par 
rapport aux autres. Elle propose une methode de decomposition, non pas basee 
uniquement sur ce que le systeme fait, mais plutot sur l'integration de ce que le 
systeme est et fait. 
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Figure 6 : Decomposition objet integrant la structure et le comportement (notation de 

Booch). 

Initialement basee sur l'utilisation d'objets en tant qu' abstractions du monde reel, 
l'approche objet a pour but une modelisation des proprietes statiques et 
dynamiques de l'environnement dans lequel sont definis les besoins, appele le 
domaine du probleme. Elle formalise notre perception du monde et des 
phenomenes qui s'y deroulent, et met en correspondance l'espace du probleme et 
l'espace de la solution (l'ensemble des artefacts de realisation), en preservant la 
structure et le comportement du systeme analyse. Les fonctions se representent 
alors par des formes de collaboration entre les objets qui composent le systeme. 
Le couplage devient dynamique, et les evolutions fonctionnelles ne remettent 
plus en cause la structure statique du logiciel. 

Lorsque le probleme est totalement compris, le systeme informatique est realise en 
composant les representations informatiques des elements simples, identifies par 
l'une des techniques de decomposition precedentes. La construction d'un 
systeme apparait done comme une demarche d' integration, une organisation 
harmonieuse de composants plus elementaires, dont la raison d'etre est notre 
maniere de gerer la complexite par la decomposition. 

Dans une organisation unifiee, la distinction des composants va de pair avec leur 
integration. La force de l'approche objet provient alors de sa double capacite a 
decomposer - differencier - et a recomposer - reunir - du fait de la richesse de 
ses mecanismes d' integration, qui concernent a la fois les aspects statiques et les 
aspects dynamiques des logiciels. L'integration apparait comme la qualite 
fondamentale des objets ; elle assure la coherence entre les composants d'un 
systeme informatique, au sein d'un modele uniforme applicable a toutes les 
phases du cycle de vie du logiciel. 

L'approche objet tire sa force de sa capacite a regrouper ce qui a ete separe, a 
construire le complexe a partir de l'elementaire, et surtout a integrer statiquement 
et dynamiquement les constituants d'un systeme. 
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Les objets 



L'objet est une unite atomique formee de l'union d'un etat et d'un comportement. 
II fournit une relation d'encapsulation qui assure a la fois une cohesion interne 
tres forte et un faible couplage avec l'exterieur. L'objet revele son vrai role et sa 
vraie responsabilite lorsque, par l'intermediaire de l'envoi de messages, il s'insere 
dans un scenario de communication. 





Comportement visible 


Un objet 






Etat interne cache 





Figure 7 : Chaque objet contient un etat interne qui lui est propre et un comportement 
accessible aux autres objets. 

Le monde dans lequel nous vivons est constitue d'objets materiels de toutes 
sortes. La taille de ces objets est tres variable : certains sont petits, comme les 
grains de sable, et d'autres tres gros, comme les etoiles. Notre perception intuitive 
de ce qui constitue un objet est fondee sur le concept de masse, c'est-a-dire sur 
une grandeur qui caracterise la quantite de matiere d'un corps. 

Par extension, il est tout a fait possible de definir d'autres objets, sans masse, 
comme les comptes en banques, les polices d'assurance ou encore les equations 
mathematiques. Ces objets correspondent alors a des concepts plutot qu'a des 
entites physiques. 

Toujours par extension, les objets peuvent egalement appartenir a des mondes 
virtuels, par exemple, en association avec Internet, pour creer des communautes 
de personnes qui ne sont pas situees au meme point geographique. 

Les objets informatiques definissent une representation abstraite des entites d'un 
monde reel ou virtuel, dans le but de les piloter ou de les simuler. Cette 
representation abstraite peut etre vue comme une sorte de miroir informatique, qui 
renvoie une image simplified d'un objet qui existe dans le monde percu par 
l'utilisateur. Les objets informatiques, que nous appellerons desormais objets, 
encapsulent une partie de la connaissance du monde dans lequel ils evoluent. 

Les utilisateurs des technologies objet ont pris l'habitude de considerer les objets 
comme des etres animes d'une vie propre, de sorte qu'ils les presentent souvent 
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dans une vision anthropomorphique . Ainsi, les objets sont souvent designes en 
anglais par she ou he plutot que par it. 

Comme les etres vivants, les objets du monde reel qui nous entourent naissent, 
vivent et meurent. La modelisation objet permet de representer le cycle de vie des 
objets au travers de leurs interactions. 

En UML, un objet se represente sous la forme d'un rectangle ; le nom de l'objet 
est souligne. Le diagramme suivant represente trois objets. 



Un objet 



Un autre objet 



Encore un obiet 



Figure 8 : En UML les objets se representent au moyen d'icones rectangulaires. 

Le diagramme suivant represente plusieurs clients d'une banque et les comptes 
associes a chacun de ces clients. Les traits qui relient les objets symbolisent les 
liens qui existent entre un client particulier et un compte particulier. Le graphique 
presente egalement un rectangle dont le coin haut droit est replie : il s'agit de la 
representation d'une note, c'est-a-dire d'une information de clarification 
optionnelle exprimee dans un format libre, afin de faciliter la comprehension du 
diagramme. Les traits discontinus permettent de relier n'importe quel ensemble 
d'elements de modelisation a une note descriptive. 



Deux clients k| 
de la banque 



Philippe 



Compte courant 



Didier 



2Z\ 



Assurance vie 



Compte eparqne loqement 



Compte eparqne 



Compte courant 



Figure 9 : Representation graphique d'objets ayant un lien entre eux. 



3 Wirfs-Brock R., Wilkerson B., Wiener L. 1990, Designing Object-Oriented 
Software. Prentice-Hall, Englewood Cliffs, NJ. 
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II est souvent difficile de trouver un nom pour designer chaque objet ; c'est 
pourquoi la notation permet d'indiquer un nom generique plutot que leur nom 
individuel. Cet artifice permet de parler des objets en termes generaux, tout en 
evitant la multiplication de noms du type ga, bu, zo ou meu, qui vehiculent un 
contenu semantique tres approximatif . 

Le diagramme suivant montre des eleves et des professeurs. Les deux points 
precisent qu'il s'agit d'objets anonymes, de genre Eleve et Professeur. 



Eleve 



Eleve 



: Professeur 



Eleve 



Eleve 



: Professeur 



Figure 10 : Representation d'objets anonymes. 



Caracteristiques fondamentales d'un objet 

La presentation des caracteristiques fondamentales d'un objet permet de 
repondre de maniere plus formelle a la sempiternelle question : « mais qu'est-ce 
qui definit un objet ? ». Tout objet presente les trois caracteristiques suivantes : 
un etat, un comportement et une identite. 



Objet = Etat + Comportement + Identite 



Un objet doit apporter une valeur ajoutee par rapport a la simple juxtaposition 
d' informations ou de code executable. Un objet sans etat ou sans comportement 
peut exister marginalement, mais dans tous les cas, un objet possede une identite. 

L'etat 

L'etat regroupe les valeurs instantanees de tous les attributs d'un objet sachant 
qu'un attribut est une information qui qualifie l'objet qui le contient. Chaque 
attribut peut prendre une valeur dans un domaine de definition donne. L'etat d'un 
objet, a un instant donne, correspond a une selection de valeurs, parmi toutes les 
valeurs possibles des differents attributs. 

Le diagramme suivant montre une voiture qui contient les valeurs de trois 
attributs differents : la couleur, la masse et la puissance fiscale. 
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Une voiture 




Bleu 




979 ka 


12 CV 



Figure 11 : L'etat regroupe les valeurs des differents attributs qui caracterisent un objet. Dans 
le cas d'une voiture, la couleur ou la masse font partie de l'etat. 

L'etat evolue au cours du temps ; ainsi, lorsqu'une voiture roule, la quantite de 
carburant diminue, les pneus s'usent et la temperature dans l'habitacle varie. 
Certaines composantes de l'etat peuvent etre constantes : c'est le cas par exemple 
de la marque de la voiture, ou encore du pays de sa construction. Toutefois, en 
regie generale, l'etat d'un objet est variable et peut etre vu comme la consequence 
de ses comportements passes. 

Dans 1' exemple suivant, une voiture donnee parcourt une centaine de kilometres ; 
pendant qu'elle se deplace, la valeur qui symbolise la quantite de carburant 
diminue avec la distance parcourue. 



Une voiture 
| 30 litres j 

\ 

s 

\ 

\ 

Apres un parcours l\ 
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Une voiture 
\ 20 litres] 



Figure 12 : L'etat d'un objet a un moment donne est la consequence des comportements 

passes. 

Le comportement 

Le comportement regroupe toutes les competences d'un objet et decrit les actions 
et les reactions de cet objet. Chaque atome de comportement est appele 
operation. Les operations d'un objet sont declenchees suite a une stimulation 
externe, representee sous la forme d'un message envoye par un autre objet. 

Dans le diagramme suivant, selon la valeur du message, Y Operation 1 ou 
I' Operation 2 est declenchee. 
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Un message 



Un autre obiet 



Un obiet 



[Operation 2 
L_i I 



Operation 1 ^ 
{...} 



Figure 13 : En reponse a un message, V objet destinataire declenche un comportement. Le 
message sert de selecteur pour determiner V operation a executer. 

Les interactions entre objets se represented au moyen de diagrammes dans 
lesquels les objets qui interagissent sont relies entre eux par des lignes continues 
appelees liens. La presence d'un lien signifie qu'un objet connait ou voit un autre 
objet. Les messages naviguent le long des liens, a priori dans les deux directions. 
Dans l'exemple suivant, l'objet A demande a l'objet B de manger, et l'objet B 
demande a l'objet C de dormir. Ceci sous-entend que l'objet B possede la faculte 
de manger et que l'objet C est capable de dormir. 

r 1 

I B 

Manger^ j 


n \ 

a r \ \ 

l - I \ \ Dormir 

! ! \ -\i 



Figure 14 : Representation d'une interaction entre des objets. 



L'etat et le comportement sont lies ; en effet, le comportement a un instant donne 
depend de l'etat courant, et l'etat peut etre modifie par le comportement. II n'est 
possible de faire atterrir un avion que s'il est en train de voler, c'est-a-dire que le 
comportement Atterrir n'est valide que si l'information En Vol est valide. 
Apres l'atterrissage, l'information En Vol devient invalide, et l'operation 
Atterrir n'a plus de sens. L'exemple suivant montre les liens entre l'etat et le 
comportement. 
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Decoller 




: Avion 




: Tour de controle 


S> 




Au sol 















Figure 15 : Le comportement et les attributs sont lies. 



L'identite 

En plus de son etat, un objet possede une identite qui caracterise son existence 
propre. L'identite permet de distinguer tout objet de facon non ambigue, et cela 
independamment de son etat 4 . Cela permet, entre autres, de distinguer deux objets 
dont toutes les valeurs d' attributs sont identiques. 

L'identite est un concept, elle ne se represente pas de maniere specifique en 
modelisation. Chaque objet possede une identite de maniere implicite. 

En phase de realisation, l'identite est souvent construite a partir d'un identifiant 
issu naturellement du domaine du probleme. Nos voitures possedent toutes un 
numero d'immatriculation, nos telephones un numero d'appel, et nous-memes 
sommes identifies par notre numero de securite sociale. Ce genre d' identifiant, 
appele egalement cle naturelle, peut etre rajoute dans l'etat des objets afin de les 
distinguer. II ne s'agit toutefois que d'un artifice de realisation, car le concept 
d'identite reste independant du concept d'etat. 



Contraintes de realisation 

Les notions d'etat, de comportement et d'identite decrites dans le chapitre 
precedent, s'appliquent aux objets de maniere tres generate, quel que soit 
l'environnement de realisation. Toutefois, les objets peuvent egalement posseder 
des caracteristiques plus informatiques, liees aux contingences de 
realisation comme la distribution des programmes, les bases de donnees ou les 
developpements multilangages. 



4 Khoshafian, S. N., Copeland G. P. 1986, Object Identity. OOPSLA'86 Conference 
Proceedings. 
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La persistance des objets 

La persistance designe la capacite d'un objet a transcender le temps ou l'espace. 
Un objet persistant sauvegarde son etat dans un systeme de stockage permanent, 
de sorte qu'il est possible d'arreter le processus qui l'a cree sans perdre 
l'information representee par l'objet (passivation de l'objet). Par la suite, l'objet 
peut etre reconstruit (activation de l'objet) par un autre processus et se 
comportera exactement comme dans le processus initial. Les objets non 
persistants sont dits transitoires ou ephemeres. Par defaut, les objets ne sont pas 
considered comme persistants. 



Figure 16 : L'etat des objets persistants est sauvegarde dans un systeme de stockage 



Dans leur ensemble, les langages de programmation objet ne proposent pas de 
support direct pour assurer la persistance des objets. Cela est regrettable et 
oblige a recourir a des artifices exterieurs pour assurer la persistance des objets. 
Les constructeurs de bases de donnees fournissent des solutions pour la 
sauvegarde des objets, soit totalement objet, soit hybrides. 

La transmission des objets 

La problematique de la persistance des objets est tres proche de celle de la 
migration des objets d'un processus vers un autre. En effet, il s'agit alors 
d'envoyer un objet par un moyen de communication quelconque d'un espace 
d'adressage vers un autre espace d'adressage. Cette operation s'apparente 
etroitement a la demarche de passivation et d'activation decrite precedemment. 
Les objets ne voyagent pas reellement : l'objet original est analyse lors de 
remission, la description de l'objet est transmise au travers du support de 
communication, un clone de l'objet est reconstruit lors de la reception et l'objet 
initial est supprime. Les amateurs de Star Trek auront reconnu le principe de la 
tele-transportation 5 . 



5 MetzgerG. 1996, Beam me up, Spock. There is no life on this planet. 
Communication privee. 



: Objet persistant 




permanent. 
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d'origine 



Un clone 



: Support de communication ] 



Figure 17 : Les objets peuvent etre transmis le long d'un support de communication. 



Les objets miroirs 

Les objets miroirs constituent une alternative a la transmission des objets. Un 
objet miroir se comporte comme un autre objet avec lequel il est synchronise. Le 
client manipule le miroir comme s'il manipulait I'objet distant, ce qui permet de 
dissimuler toute la complexite de la communication au fond des objets miroirs. 



Contexte A 


1 Contexte B 


1 ,, . . 1 i :> 

l Un miroir i 1 
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Figure 18 : Le miroir renvoie dans le contexte A, I'image d'un objet defini dans le contexte B. 



Communication entre objets 

Les systemes informatiques a objets peuvent etre vus comme des societes 
d'objets qui travaillent en synergie afin de realiser les fonctions de 1' application. 
Lors de l'execution d'un programme, les objets contribuent solidairement au bon 
deroulement de l'application informatique. Le comportement global d'une 
application repose done sur la communication entre les objets qui la composent. 

De ce fait, l'etude des formes de communication entre objets du domaine est de 
premiere importance dans la modelisation objet et, d'ailleurs, la grande difference 
entre l'approche fonctionnelle et l'approche objet reside precisement dans cette 
articulation qui reduit le couplage entre la structure et la fonction. 

Categories de comportement 

Les objets interagissent pour realiser les fonctions de l'application. Selon la 
nature des interactions, e'est-a-dire selon la direction des messages echanges, il 
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est possible de decrire de maniere generale le comportement des objets. II est 
frequent de retenir trois categories de comportement : les acteurs, les serveurs et 
les agents. 



Un agent 



Un acteur 


> 


Un serveur 









Figure 19 : Les objets peuvent etre regroupes dans trois categories selon la nature de leur 

comportement. 

Les acteurs 6 sont toujours des objets a l'origine d'une interaction. Ce sont 
generalement des objets actifs, c'est-a-dire qu'ils possedent un fil d' execution 
(thread) et que ce sont eux qui passent la main aux autres objets. 

Les serveurs, au contraire, ne sont jamais a l'origine d'une interaction, mais sont 
toujours les destinataires des messages. Ce sont souvent des objets passifs qui 
attendent qu'un autre objet ait besoin de leurs services. Dans ce cas, le flot de 
controle est passe au serveur par 1' objet qui envoie le message et est recupere 
apres execution du service. 



Un client 



Un serveur 



Figure 20 : L'objet client passe la main a I'objet serveur, puis attend la fin du service avant 

de reprendre son execution. 



Les agents cumulent les caracteristiques des acteurs et des serveurs. Ces objets 
ont un comportement tres proche de celui des humains ; ils peuvent interagir avec 
les autres objets a tout moment, de leur fait ou suite a une sollicitation externe. 



6 Le terme acteur est egalement employe pour designer une categorie 
d'utilisateurs dans le modele des cas d'utilisation (use case) qui est presente plus 
loin dans l'ouvrage. 
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Les agents sont a la base du mecanisme de delegation qui permet a un objet de se 
comporter comme un paravent devant un autre objet. Les agents decouplent les 
objets clients des objets fournisseurs, en introduisant une indirection dans le 
mecanisme de propagation des messages. De cette maniere, un client peut 
communiquer avec un serveur qu'il ne connait pas directement et, de plus, le 
serveur peut changer entre deux passages de messages. 

Dans l'exemple suivant, le client communique indirectement avec le premier 
serveur sans le connaitre et sans savoir qu'il existe deux autres serveurs. Le 
routage des messages du client vers le serveur est assure dynamiquement par 
l'agent intermediate. 



Routage 
dynamique 



5 



Serveur 1 



Un client 


— ; -> 


Un aqent 
/ 




Serveur 2 







Objet 
parave 



Serveur 3 



Figure 21 : Illustration du mecanisme de delegation. 



Le concept de message 

L'unite de communication entre objets s'appelle le message. Le message est le 
support d'une relation de communication qui relie, de facon dynamique, les objets 
qui ont ete separes par le processus de decomposition. II permet l'interaction de 
maniere flexible, en etant a la fois agent de couplage et agent de decouplage. C'est 
lui qui assure la delegation des taches et garantit le respect des contraintes. Le 
message est un integrateur dynamique qui permet de reconstituer une fonction de 
l'application par la mise en collaboration d'un groupe d'objets. II acquiert toute sa 
force d'integration lorsqu'il est associe au polymorphisme et a la liaison 
dynamique, definis plus loin dans ce chapitre. Les messages, comme le montre la 
figure suivante, sont representes par des fleches placees le long des liens qui 
unissent les objets. 
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Figure 22 : Les objets communiquent en echangeant des messages. 



Un message regroupe les flots de controle et les flots de donnees au sein d'une 
entite unique. La notion de message est un concept abstrait qui peut etre mis en 
oeuvre selon de nombreuses variantes, comme l'appel de procedure, l'evenement 
discret, l'interruption, le datagramme UDP, la recherche dynamique, etc. 

Le diagramme suivant decrit completement un message. La fleche simple indique 
le flot de controle et les fleches decorees de petits cercles montrent les flots de 
donnees. 



Figure 23 : Les differentes fleches montrent le flot de controle et les flots de donnees. 

Categories de messages 

II existe cinq categories principales de messages : 

• les constructeurs qui creent des objets, 

• les destructeurs qui detruisent des objets, 

• les selecteurs qui renvoient tout ou partie de l'etat d'un objet, 

• les modificateurs qui changent tout ou partie de l'etat d'un objet, 

• les iterateurs qui visitent l'etat d'un objet ou le contenu d'une structure de 
donnees qui contient plusieurs objets. 



Message 

> 

Donnee A O — >■ 



Obiet 1 



< — O Donnee B 



Obiet 2 
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L'exemple suivant montre une classe C++ dont les fonctions membres ont ete 
regroupees selon la classification proposee plus haut : 

class Lapin 
{ 

public: 

// Constructeurs 
Lapin(); 

Lapin(const Lapin &right); 
// Destructeur 
~Lapin(); 
// Assignation 

const Lapin & operator= (const Lapin Sright); 
// Egalite 

int operator==(const Lapin &right) const; 
int operator!=(const Lapin &right) const; 
// Autres Operations 
void Manger(); 
void Dormir(); 
// Selecteurs 

const String Nom() const; 
const Int Age() const; 
// Modifieurs 

void ChangerNom(const String value); 

void ChangerAge(const Int value); 
private: 
String Nom; 
Int Age; 

}; 

Figure 24 : Exemple de classe C+ + dont les fonctions membres ont ete regroupees selon les 
grandes categories de messages. 

Formes de synchronisation des messages 

Les formes de synchronisation des messages decrivent la nature des mecanismes 
de communication qui permettent le passage de messages d'un objet vers un 
autre objet. 

La notion de synchronisation prend tout son interet lorsque plusieurs objets sont 
actifs simultanement et qu'il faut, par exemple, proteger l'acces a des objets 
partages. Le diagramme suivant montre un objet partage qui assure l'interface 
vers un dispositif d'entree-sortie. 



30 - Modelisation objet avec UML 



Ecrivain 1 



Afficher 



Ecrivain 2 



Afficher -j 



: Terminal 



Afficher 



Ecrivain 3 



Ressource 
critique 



Figure 25 : Exemple d'un objet Terminal accede par plusieurs objets Ecrivain. 

Dans une application purement sequentielle, les ecrivains parlent au terminal 
chacun a leur tour et l'affichage sur l'ecran ne pose aucun probleme. En revanche, 
des lors que plusieurs objets Ecrivain peuvent etre actifs simultanement, 
l'objet Terminal devient une ressource critique dont il convient de proteger les 
acces par synchronisation des envois de messages. 

La notion de synchronisation precise la nature de la communication, et les regies 
qui regissent le passage des messages. II existe cinq grandes categories d'envoi 
de message : 

• Envoi de message simple. Cette categorie convient pour les systemes a un 
seul flot d'execution, dans lesquels un seul objet a la fois est actif. Le passage 
du controle s'effectue lors de l'envoi d'un message de l'objet actif vers un 
objet passif. Un envoi de message simple se represente par une fleche simple. 

I 1 r 1 

Un expediteur | J Un destinataire | 

I J — > 1 J 

Envoi simple 



Figure 26 : Representation d'un envoi de message simple. 

• Envoi de message synchrone. Un message synchrone ne declenche une 
operation que lorsque le destinataire accepte le message. Une fois le message 
envoye, l'expediteur est bloque jusqu'a ce que le destinataire accepte le 
message. Un envoi de message synchrone se represente par une fleche barree 
d'une croix. 

j 1 r 1 

j Un expediteur | J Un destinataire | 

I ! ->e> 1 J 

Envoi synchrone 



Figure 27 : Representation d'un envoi de message synchrone. 



2 - L'approche objet - 31 



• Envoi de message derobant. Un message derobant declenche une operation 
seulement si le destinataire s'est prealablement mis en attente du message. Ce 
type de synchronisation correspond a une tolerance d' attente inverse de celle 
de l'envoi de message synchrone. Dans le cas d'un message synchrone, 
l'expediteur accepte d'attendre ; dans le cas d'un message derobant, le 
destinataire accepte d'attendre. Un envoi de message derobant se represente 
par une Heche qui se retourne vers l'expediteur. 



Un expediteur 




Un destinataire 









Envoi derobant 

Figure 28 : Representation d'un envoi de message derobant. 

• Envoi de message minute. Un message minute bloque l'expediteur pendant un 
temps donne, en attendant la prise en compte par le destinataire. L'expediteur 
est libere si la prise en compte n'a pas eu lieu au bout du temps specifie dans 
la description de l'envoi du message minute. L'envoi de message derobant 
correspond au cas limite d'un envoi minute avec un delai d'attente nul. Un 
envoi de message minute se represente par une fleche decoree d'une montre 
symbolisee par un petit cercle. 



Un expediteur 




Un destinataire 









Envoi minute 



Figure 29 : Representation d'un envoi de message minute. 

• Envoi de message asynchrone. Un message asynchrone n'interrompt pas 
l'execution de l'expediteur. L'expediteur envoie le message sans savoir quand, 
ni meme si, le message sera traite par le destinataire. Du point de vue du 
destinataire, un envoi asynchrone doit pouvoir etre pris en compte a tout 
moment. Un envoi de message asynchrone se represente par une demi-fleche. 



Un expediteur 




Un destinataire 









Envoi asynchrone 



Figure 30 : Representation d'un envoi de message asynchrone. 

La precision de la forme de synchronisation des messages est souvent operee en 
conception, pour realiser par exemple une exclusion mutuelle autour d'une 
ressource critique. Le diagramme suivant montre que les differents ecrivains 
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communiquent de facon synchrone avec le terminal. Le terminal serialise les 
affichages et les differents ecrivains doivent attendre chacun leur tour. 



Ecrivain 1 
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Figure 31 : Exemple de communication par messages synchrones. 



La representation de la synchronisation des messages est egalement utile en 
analyse, comme le montre le diagramme suivant qui illustre une communication 
par telephone. Antoine appelle Marc au telephone ; la communication ne peut 
avoir lieu que si Marc decroche. Antoine n'attend pas indefiniment et peut 
raccrocher apres trois sonneries. 

! Marc I 

! 

{3 sonneries} 

| Antoine TApppi 
J 



Figure 32 : Exemple d'une communication minutee. 



La communication par voie epistolaire suit un schema asynchrone. Gerard 
envoie une lettre a Bernard ; il ne sait pas quand la lettre arrivera, ni meme si la 
lettre arrivera, et il n'attend pas que Bernard la regoive. 

r 1 r 1 

! Gerard i \ Bernard 

I J — ^ I l 

Lettre par la poste 



Figure 33 : Exemple d'une communication asynchrone. 



Representation des interactions entre les objets 

Les objets interagissent pour realiser collectivement les services offerts par les 
applications. Les diagrammes d'interaction representent les objets les uns par 
rapport aux autres et montrent comment ils communiquent au sein d'une 
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interaction. Chaque interaction possede un nom et un contexte de validite qu'il 
convient de preciser de maniere textuelle. 

II existe deux sortes de diagrammes d'interaction : les diagrammes de 
collaboration et les diagrammes de sequence. 

Les diagrammes de collaboration 

Les diagrammes de collaboration correspondent aux diagrammes utilises dans les 
exemples precedents. Ces diagrammes montrent quelques objets dans une 
situation donnee. Les objets sont representes sous forme de rectangles, des liens 
relient les objets qui se connaissent (c'est-a-dire qui peuvent interagir) et les 
messages echanges par les objets sont representes le long de ces liens. L'ordre 
d'envoi des differents messages est materialise par un numero place en tete du 
message. 



Le diagramme ci-dessus se lit de la maniere suivante : 

le scenario debute par un objet A qui envoie un message X a un objet B, puis 
I ' objet B envoie un message Y a un objet C, et enfin C s 'envoie un message Z. 

Le message Z est un artifice de notation pour representer une activite ayant lieu 
dans l'objet C. 

Les diagrammes de collaboration sont particulierement indiques pour la phase 
exploratoire qui correspond a la recherche des objets. L'agencement des objets 
dans le diagramme peut evoquer la disposition spatiale des objets dans le monde 
reel, tout en montrant une forme d'interaction. Les diagrammes d' objets decrivent 
a la fois la structure statique par des liens entre objets, et le comportement, a 
travers des envois de messages le long de ces liens. Ce type de diagramme 
possede cependant les limites habituelles des representations graphiques - la 
visualisation claire d'un nombre limite d' informations de sorte que seule une 
petite collaboration est representable. Le diagramme suivant illustre les limites du 
diagramme de collaboration : le grand nombre de messages obscurcit le 
diagramme. 



A 




1:X 



Figure 34 : Exemple de diagramme de collaboration. 
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Figure 35 : Illustration de la limite d'expressivite d'un diagramme de collaboration. 



Les diagrammes de sequence 

Les diagrammes de sequence montrent a peu pres les memes informations que les 
diagrammes precedents, mais l'accent est mis sur la communication, au detriment 
de la structure spatiale. Chaque objet est represents par une barre verticale. Le 
temps s'ecoule de haut en bas, de sorte que la numerotation des messages est 
optionnelle. 

Le passage d'un diagramme a l'autre est possible automatiquement, des lors que 
seules les informations de presence d'objets et de communication sont retenues. 
Le diagramme de collaboration precedent correspond au diagramme de sequence 
suivant : 
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Figure 36 : Diagramme de sequence derive du diagramme de collaboration precedent. 

Le diagramme precedent montre uniquement la chronologie des messages. Les 
barres verticales peuvent etre decorees de bandes rectangulaires, afin de montrer 
la distribution du flot de controle parmi les differents objets. 



A 




B 









M1 



M4 



M7 



M9 



M10 



M2 



M3 



M5 



M6 



-I) 



1 



M8 



Figure 37 : Representation de la distribution duflot de controle parmi les objets. 
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Les deux types de diagrammes d' interaction sont interessants pour la 
modelisation objet. Le diagramme de sequence est particulierement bien adapte 
pour la representation d'interactions complexes, du fait de sa forme quasi 
tabulaire. Le diagramme de collaboration se prete mieux a la decouverte des 
abstractions, car il permet de montrer les objets du domaine dans une disposition 
physique proche de la realite. Dans la pratique, il est frequent de commencer par 
representer les principaux objets du domaine dans des diagrammes de 
collaboration, puis, une fois les objets bien identifies, de migrer vers les 
diagrammes de sequence pour la representation des interactions dans toute leur 
complexite. 



Les classes 



Le monde reel est constitue de tres nombreux objets en interaction. Ces objets 
constituent des amalgames souvent trop complexes pour etre compris dans leur 
integralite du premier coup. Pour reduire cette complexite - ou du moins pour la 
maitriser - et comprendre ainsi le monde qui l'entoure, l'etre humain a appris a 
regrouper les elements qui se ressemblent et a distinguer des structures de plus 
haut niveau d'abstraction, debarrassees de details inutiles. 

La demarche d'abstraction 

L'abstraction est une faculte des etres humains qui consiste a concentrer la 
reflexion sur un element d'une representation ou d'une notion, en portant 
specialement l'attention sur lui et en negligeant tous les autres. La demarche 
d'abstraction procede de 1' identification des caracteristiques communes a un 
ensemble d' elements, puis de la description condensee - analogue a la 
description d'un ensemble en comprehension - de ces caracteristiques dans ce 
qu'il est convenu d'appeler une classe. La demarche d'abstraction est arbitraire : 
elle se definit par rapport a un point de vue. Ainsi, un objet du monde reel peut 
etre vu au travers d'abstractions differentes, ce qui implique qu'il est important de 
determiner quels sont les criteres pertinents dans le domaine d'application 
considere. 

La classe decrit le domaine de definition d'un ensemble d'objets. Chaque objet 
appartient a une classe. Les generalites sont contenues dans la classe et les 
particularites sont contenues dans les objets. Les objets informatiques sont 
construits a partir de la classe, par un processus appele instanciation. De ce fait, 
tout objet est une instance de classe. 

Les langages objet permettent de decrire et de manipuler des classes et leurs 
instances. Cela signifie que l'utilisateur peut construire en machine une 
representation informatique des abstractions qu'il a l'habitude de manipuler 
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mentalement, sans traduction vers des concepts de plus bas niveau (comme les 
fonctions ou les procedures des langages de programmation non objet). 

Les langages objet reduisent la distance entre notre facon de raisonner (par 
abstraction) et le langage compris par les ordinateurs, de sorte qu'il est 
globalement plus facile de realiser une application avec un langage objet qu'avec 
un langage traditionnel, meme si l'approche objet demande une remise en cause 
des habitudes acquises. 



Objets 



Types de donnees abstraits 



Fonctions 



Mnemoniques 



Codes binaires 



Programmation ^ 
plus abstraite 



Simplification 



Programmation 
plus difficile 



Figure 38 : Les langages de programmation objet permettent une programmation plus 

abstraite. 



Representation graphique des classes 

Chaque classe est representee sous la forme d'un rectangle divise en trois 
compartiments. Le premier compartiment contient le nom de la classe, le second 
les attributs et le dernier les operations. Par defaut, les attributs sont caches et les 
operations sont visibles. Les compartiments peuvent etre supprimes pour alleger 
les diagrammes. 



I Nom de classe i 

lAttributs i 
I _, 

lOperations( ) ! 



Figure 39 : Representation graphique des classes. 

Les quelques exemples suivants illustrent l'emploi des classes pour decrire de 
maniere generale quelques objets de notre entourage. 
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La classe Motocyclette contient les attributs Couleur, Cylindree et 
Vitesse maximale. La classe regroupe egalement les operations applicables 
aux instances de la classe, comme ici les operations Demarrer () , 
Accelerer () et Freiner () . 



Motocyclette 

Couleur 
Cylindree 
Vitesse maximale 



Demarrer( ) 
Accelerer( ) 
Freiner( ) 



Figure 40 : Exemple d'une classe Motocyclette. 

L'ensemble des nombres complexes regroupe des nombres qui ont une partie 
reelle et une partie imaginaire. La connaissance de la representation interne du 
nombre complexe - cartesienne ou polaire - n'est pas necessaire pour utiliser les 
operations decrites dans l'exemple suivant. La classe Nombre complexe 
cache les details de sa realisation. 



Nombre complexe 

Additionner( ) 
Soustraire( ) 
Multiplied ) 

Diviser( ) 

Prendre le module( ) 
Prendre l'argument( ) 
Prendre la partie reelle( ) 
Prendre la partie imaginaire( ) 



Figure 41 : La classe Nombre complexe dissimule les details de sa representation interne. 

Un televiseur est un equipement electronique d'une complexite non negligeable, 
qui peut neanmoins etre utilise aisement meme par de tres petits enfants. Le 
televiseur offre une abstraction simple, au travers de quelques operations 
elementaires comme Changer de programme ou Regler le volume 
sonore. 
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Televiseur 
Allumer( ) 
Eteindre( ) 

Changer de programme( ) 
Regler le volume( ) 



Figure 42 : Exemple d'une classe Televiseur. 



Une transaction bancaire est une abstraction d'une operation immaterielle, qui 
reifie une interaction entre un client et une banque. Le detail de realisation des 
transactions courantes, comme le retrait ou le depot, ne sont pas connus du client 
qui se contente d'indiquer le compte sur lequel il desire operer et le montant 
concerne. Le compte est une autre abstraction du domaine bancaire. 

L' abstraction dissimule la complexite de la gestion des comptes, de sorte que les 
transactions peuvent etre realisees simplement par le client tout seul, depuis un 
guichet automatique ou depuis un Minitel. 
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Figure 43 : Representation d'une partie du domaine bancaire. 



L'electronique des circuits integres exploite la notion d'abstraction avec 
beaucoup de succes. La complexite electronique et les details internes sont 
totalement invisibles pour l'utilisateur de ces composants. Dans le cas des portes 
logiques, le circuit integre reifie une abstraction fonctionnelle. 
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Figure 44 : Exemple de reification d'une abstraction fonctionnelle. 

Tous les types de donnees abstraits manipules par les informaticiens sont, 
comme leur nom l'indique, des abstractions decrites en termes d'operations 
applicables sur des valeurs. Ce genre d' abstraction appartient typiquement a la 
conception, et n'apparait jamais en analyse ou le terme collection est suffisant 
pour designer les regroupements d'objets. 



Liste 



Premier( ) 
Dernier( ) 
Ajouter( ) 
Retirer( ) 
Cardinality ) 



Pile 



Empiler( ) 
Depiler( ) 
Cardinality ) 



Arbre binaire 



Sous-arbre gauche( ) 
Sous-arbre droit( ) 
Traverser en profondeur( 



Figure 45 : Types de donnees abstraits presentes sous la forme de classes. 



Description des classes 

La description des classes est separee en deux parties : 

• la specification d'une classe qui decrit le domaine de definition et les 
proprietes des instances de cette classe, et qui correspond a la notion de type 
telle qu'elle est definie dans les langages de programmation classiques, 

• la realisation qui decrit comment la specification est realisee et qui contient le 
corps des operations et les donnees necessaires a leur fonctionnement. 

Une classe passe un contrat avec d'autres classes ; elle s'engage a fournir les 
services publies dans sa specification et les autres classes s'engagent a ne pas 
faire usage de connaissances autres que celles decrites dans cette specification. 
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Fournisseur 



I Les contrats ^ 
Idecrivent les I 
idependances | 
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l classes. ; 
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Client 1 
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J— 



I 




— I 



L. 



Figure 46 : Les classes passent un contrat base sur la specification du fournisseur. 

Les langages modulaires permettent la compilation separee de la specification et 
de la realisation, de sorte qu'il est possible de valider tout d'abord la coherence 
des specifications (appelees aussi interfaces) et de s'attaquer plus tard a la 
realisation. 

Selon les langages de programmation, les concepts de type, de description et de 
modules sont plus ou moins integres dans le concept de classe : 

• En Ada 95 par exemple, une classe est construite explicitement, en placant un 
type (prive) accompagne de ses operations dans un module (paquetage). 
Cette approche permet notamment de placer plusieurs types dans un module 
et done de realiser 1' equivalent des classes amies de C++. 

• En C++ au contraire, la classe est realisee directement par une construction 
syntaxique qui englobe les notions de type, de description et de module. La 
classe peut etre degradee afin d'obtenir un module seul, par l'ajout du mot-cle 
static devant toutes les operations. 

• En Java, comme en C++, la classe est l'integration des notions de type, de 
description et de module, mais il existe en plus une notion de module plus 
large (le paquetage) qui peut contenir plusieurs classes. 

La separation entre la specification et la realisation des classes participe a 
l'elevation du niveau d' abstraction. Les traits remarquables sont decrits dans les 
specifications alors que les details sont confines dans les realisations. 
L'occultation des details de realisation est appelee encapsulation. 

L'encapsulation presente un double avantage. D'une part, les donnees 
encapsulees dans les objets sont protegees des acces intempestifs - ce qui 
permet de garantir leur integrite - et d'autre part, les utilisateurs d'une abstraction 
ne dependent pas de la realisation de 1' abstraction mais seulement de sa 
specification, ce qui reduit le couplage dans les modeles. 
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Figure 47 : Les donnees encapsulees dans un objet ne sont pas accessibles depuis Vexterieur. 

Par defaut, les valeurs d'attributs d'un objet sont encapsulees dans l'objet et ne 
peuvent pas etre manipulees directement par les autres objets. Toutes les 
interactions entre les objets sont effectuees en declenchant les diverses 
operations declarees dans la specification de la classe et accessibles depuis les 
autres objets. 

Les regies de visibilite viennent completer ou preciser la notion d'encapsulation. 
Ainsi, il est possible d'assouplir le degre d'encapsulation, mais aussi de 
protection, au profit de certaines classes utilisatrices bien particulieres, designees 
dans la specification de la classe fournisseur. L'interet de briser l'encapsulation 
est par exemple de reduire le temps d'acces aux attributs en supprimant la 
necessite de recourir a des operations de type selecteur. 

Les trois niveaux distincts d'encapsulation couramment retenus correspondent a 
ceux proposes par le langage de programmation C++ : 

• Le niveau le plus fort est appele niveau prive ; la partie privee de la classe est 
alors totalement opaque et seuls les amis (au sens C++) peuvent acceder aux 
attributs places dans la partie privee. 

• II est possible de relacher legerement le niveau d'encapsulation, en plagant 
certains attributs dans la partie protegee de la classe. Ces attributs sont alors 
visibles a la fois pour les amis et les classes derivees de la classe fournisseur. 
Pour toutes les autres classes, les attributs restent invisibles. 

• Le niveau le plus faible est obtenu en plagant les attributs dans la partie 
publique de la classe. Ceci revient a se passer de la notion d'encapsulation et 
a rendre visibles les attributs pour toutes les classes. 

Le niveau de visibilite peut etre precise dans les representations graphiques des 
classes au moyen des caracteres +, # et -, qui correspondent respectivement aux 
niveaux public, protege et prive. 
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Regies de visibilite 

+ Attribut public 
# Attribut protege 
- Attribut prive 



+ Operation publique( ) 
# Operation protegee; ] 
- Operation privee( ) 



Figure 48 : Precision des niveaux de visibilite dans les representations graphiques des classes. 



L'exemple des nombres complexes decrit precedemment foumit une bonne 
illustration des vertus de 1' encapsulation. Parce que la specification des nombres 
complexes - qui regroupe entre autres les operations d'addition, de soustraction, 
de multiplication et de division - n'est pas du tout affectee par le changement de 
representation interne (de la notation polaire a la notation cartesienne), les objets 
qui utilisent des nombres complexes - et qui dependent uniquement de la 
specification - ne sont pas affectes par cette modification. Le diagramme suivant 
montre les deux representations des nombres complexes. La partie publique de 
1' abstraction est identique dans les deux cas, mais la partie privee est differente. 



Nombre complexe 



Module 
Argument 



Addition) ) 

■ Soustraction( ) 

■ Multiplication; ) 

■ Division; ) 



Nombre complexe 



Partie reelle 
Partie imaginaire 



■ Addition; ) 

- Soustraction; ) 

- Multiplication; ) 

- Division; ) 



Figure 49 : La specification n'est pas affectee par un changement de representation interne. 

L'encapsulation reduit le couplage au sein du modele, favorise la modularite et 
facilite la maintenance des logiciels. L'encapsulation agit comme l'enceinte de 
confinement d'une centrale nucleaire : les defauts restent enfermes dans la classe 
concernee, ils ne se propagent pas dans tout le modele. 

Les criteres d' encapsulation reposent sur la forte coherence interne a l'interieur 
d'une classe et sur le faible couplage entre les classes. II ne suffit pas pour 
obtenir une bonne abstraction, de rassembler des donnees et de fournir des 
operations pour la lecture et l'ecriture de ces donnees. Une classe doit offrir une 
valeur ajoutee par rapport a la simple juxtaposition d'information. C'est le cas de la 
classe Nombre complexe qui fournit des operations arithmetiques. 
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Les relations entre les classes 



Les liens particuliers qui relient les objets peuvent etre vus de maniere abstraite 
dans le monde des classes : a chaque famille de liens entre objets correspond une 
relation entre les classes de ces memes objets. De meme que les objets sont 
instances des classes, les liens entre objets sont instances des relations entre 
classes. 



L'association 

L'association exprime une connexion semantique bidirectionnelle entre classes. 
Une association est une abstraction des liens qui existent entre les objets 
instances des classes associees. Le diagramme suivant represente des objets lies 
entre eux et les classes associees correspondantes. Les associations se 
representent de la meme maniere que les liens. La distinction entre un lien et une 
association est operee en fonction du contexte du diagramme. 







Pierre-Alain : Etudiant 


Mulhouse : Universite 


— yfriiBTl 






i ttrrtteft-_ 



Jean-Jacques : Etudiant 



Purdue : Universite 




Eric : Etudiant 


Un lien 







Anne : Etudiant 




Strasboura : Universite 










Un lioH — 








Laurence : tiuaiani 



Universite 



Une association 



Etudiant 



Figure 50 : Les liens entre les universites et les etudiants sont tous instances de l'association 
entre la classe Universite et la classe Etudiant. 



II faut noter que l'association est un concept de meme niveau d' abstraction que 
les classes. L'association n'est pas contenue par les classes ou subordonnee aux 
classes ; elle est le reflet d'une connexion qui existe dans le domaine 
d' application. 
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Pour ameliorer la lisibilite des diagrammes, l'association peut etre decoree par une 
forme verbale active ou passive. Dans les exemples suivants, le sens de lecture 
est precise par les signes < et >. 





Heberge > 




Universite 


Etudiant 





Universite 



< Etudie dans 



Etudiant 



Figure 51 : Clarification de la nature d'une association par une forme verbale. 

II est possible de preciser le role d'une classe au sein d'une association : un nom 
de role peut etre specifie de part et d'autre de l'association. L'exemple suivant 
montre deux associations entre la classe Universite et la classe Personne. 
Le diagramme precise que certaines personnes jouent le role d'etudiant, alors que 
d'autres personnes jouent le role d'enseignant. La deuxieme association porte 
egalement un nom de role du cote de la classe Universite pour indiquer que 
1' universite joue le role d'employeurpour ses enseignants. Le nommage des roles 
prend tout son interet lorsque plusieurs associations relient deux memes classes. 

Etudiant 



Universite 



Personne 



Employeur Enseignant 

Figure 52 : Clarification du role des associations par une forme nominale. 

Les roles portent egalement une information de multiplicite qui precise le nombre 
d'instances qui participent a la relation. L'information de multiplicite apparait 
dans les diagrammes de classes a proximite du role concerne. 

Le tableau suivant resume les valeurs de multiplicite les plus courantes : 



1 


Un et un seul 


0..1 


Zero ou un 


M..N 


De M a N (entiers 
naturels) 


* 


De zero a plusieurs 
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0..* 


De zero a plusieurs 


1..* 


D ' un a plusieurs 



Figure 53 : Valeurs de multiplicite conventionnelles. 



La multiplicite peut egalement etre exprimee au moyen de formules plus 
complexes. Par defaut, il n'y a pas de correlation entre les valeurs * dans un meme 
diagramme. 

Le diagramme suivant donne un exemple de representation des valeurs de 
multiplicite. 



Etudiant 
1 *. — 



Universite 




Personne 











0..1 

Employeur Enseignant 



Figure 54 : Representation du nombre d 'instances qui participent aux associations. 

Le diagramme precedent se lit de la maniere suivante : 

une universite donnee regroupe de nombreuses personnes ; certaines jouent le 
role d'etudiant, d'autres le role d' enseignant. Un etudiant donne appartient a 
une seule universite, un enseignant donne peut etre en activite ou non. 

L'agregation 

Une relation exprime une forme de couplage entre abstractions. La force de ce 
couplage depend de la nature de la relation dans le domaine du probleme. Par 
defaut, 1' association exprime un couplage faible, les classes associees restant 
relativement independantes l'une de l'autre. L'agregation est une forme 
particuliere d'association qui exprime un couplage plus fort entre classes. Une 
des classes joue un role plus important que l'autre dans la relation. L'agregation 
permet de representer des relations de type maitre et esclaves, tout et parties ou 
compose et composants. 

Les agregations representent des connexions bidirectionnelles dissymetriques. Le 
concept d'agregation est une notion purement logique, completement 
independante des choix de representation qui relevent de la conception detaillee 
et non de la modelisation. Mathematiquement, l'agregation est une relation 
transitive, non symetrique et reflexive. 

L'exemple suivant montre qu'une personne peut s'occuper de plusieurs enfants. 
La relation est de nature dissymetrique dans le domaine considere : l'adulte est 
responsable des enfants. La relation est egalement reflexive : certaines personnes 
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jouent le role de parent, d'autres jouent le role d'enfant. Une agregation se 
represente comme une association, avec en plus un petit losange place du cote de 
l'agregat. 




Enfants 



<S'occupe de 

Figure 55 : Exemple d' agregation reflexive. 

L' agregation favorise la propagation des valeurs d'attributs et des operations de 
l'agregat vers les composants. Lorsque la multiplicite de l'agregat vaut 2, la 
destruction de l'agregat entraine la destruction des composants. 

L'exemple suivant presente le cas des voitures. Chaque voiture possede un 
moteur qui ne peut etre partage avec d'autres voitures. La destruction integrale 
de la voiture entraine la destruction du moteur. 



Voiture 



o- 



Moteur 



Figure 56 : La voiture est un tout qui contient un moteur. 



Une agregation non reflexive, dont la valeur de multiplicite vaut 1 du cote de 
l'agregat, peut se realiser par contenance physique. 



Agregat 



O- 



Composants 



Agregat par contenance physique 



: Composant 



: Composant 



Figure 57 : Forme d' agregation realisable par contenance physique. 



Lorsque cette multiplicite est superieure a 1, la relation d' agregation peut se 
realiser par une forme idiomatique de type pointeur malin {smart pointer) : 
plusieurs pointeurs referencent le meme objet tout en se synchronisant pour 
desallouer l'objet au moment ou il ne sera plus reference par aucun pointeur. 
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Agregat 



O 



Composants 







: Composant 


: Aqreqat 











: Composant 



: Aqreqat 



: Composant 



Composants ^ 



Figure 58 : Realisation d'une agregation par un pointeur malin. 



Correspondances entre diagrammes de classes et 
diagrammes d'objets 

Les diagrammes de classes et les diagrammes d'objets appartiennent a deux vues 
complementaires du modele. Un diagramme de classes montre une abstraction de 
la realite, concentree sur l'expression de la structure statique d'un point de vue 
general. Un diagramme d'objets represente plutot un cas particulier, une situation 
concrete a un instant donne ; il exprime a la fois la structure statique et un 
comportement. 



I Classe 



\ 

\ * 
\ 

r 

j Relation 



0..* I 

1 



Objet 



V- 



I 
I 
I 
I 

I ' 

I 



/__ 

Lien ! 
I 



.__ r - 



| Diagramme de classes | 



V 



_j Diagramme d'objets i 



Figure 59 : Correspondances entre diagrammes de classes et diagrammes d'objets. 



Les regies suivantes gouvernent la transition entre les deux types de diagramme 
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• chaque objet est instance d'une classe et la classe de 1' objet ne peut pas 
changer durant la vie de l'objet, 

• certaines classes - appelees classes abstraites - ne peuvent pas etre 
instanciees, 

• chaque lien est instance d'une relation, 

• les liens relient les objets, les relations relient les classes, 

• un lien entre deux objets implique une relation entre les classes des deux 
objets, 

• un lien entre deux objets indique que les deux objets se connaissent et qu'ils 
peuvent echanger des messages, 

• les diagrammes d'objets qui contiennent des objets et des liens sont 
instances des diagrammes de classes qui contiennent des classes et des 
relations. 

Les diagrammes de classes et les diagrammes d'objets doivent etre coherents les 
uns par rapport aux autres. Toutefois, il faut etre conscient que le processus de 
modelisation objet n'est pas un processus lineaire, de sorte qu'il n'est pas 
souhaitable de construire un type de diagramme et ensuite d'en deriver 
integralement l'autre type. Forcer la creation d'un type de diagramme avant un 
autre limite la liberte de creation. Pour prendre une image musicale, dissocier la 
construction des diagrammes d'objets de celle des diagrammes de classes, 
reviendrait a demander a un compositeur de considerer separement la hauteur des 
notes et leur duree. 

En pratique, les diagrammes d'objets et les diagrammes de classes se construisent 
en parallele, par de nombreux allers et retours entre les deux representations. II n'y 
a aucune raison de definir les classes avant les objets. II est vrai que chaque objet 
est instance d'une classe, mais la determination de la classe peut tres bien etre 
posterieure a celle des objets. Le monde reel qui nous entoure contient des objets 
et non des classes : il semble done naturel de trouver d'abord les objets puis d'en 
abstraire les classes. En fait, il n'y a pas de regie general e ; dans certains cas, la 
structure des classes est evidente, dans d' autres cas, les objets sont plus faciles 
a identifier que les classes. 



Les hierarchies de classes 



Les hierarchies de classes ou classifications permettent de gerer la complexite en 
ordonnant les objets au sein d'arborescences de classes d' abstraction croissante. 
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Generalisation et specialisation 

La generalisation et la specialisation sont des points de vue portes sur les 
hierarchies de classes. 

La generalisation consiste a factoriser les elements communs (attributs, 
operations et contraintes) d'un ensemble de classes dans une classe plus 
generale appelee super-classe. Les classes sont ordonnees selon une hierarchie ; 
une super-classe est une abstraction de ses sous-classes. 

La generalisation est une demarche assez difficile car elle demande une bonne 
capacite d'abstraction. La mise au point d'une hierarchie optimale est delicate et 
iterative. Les arbres de classes ne poussent pas a partir de leur racine. Au 
contraire, ils se determinent en partant des feuilles car les feuilles appartiennent 
au monde reel alors que les niveaux superieurs sont des abstractions construites 
pour ordonner et comprendre. 

L'exemple suivant montre une hierarchie des moyens de transport. La fleche qui 
symbolise la generalisation entre deux classes pointe vers la classe plus generale. 



Abstractions plus generales 



Vehicule 




Vehicule terrestre 





Vehicule aerien 




Voiture 




Camion 




Avion 





Helicoptere 



Figure 60 : Exemple de hierarchie de classes construite par generalisation. 



La specialisation permet de capturer les particularites d'un ensemble d'objets non 
discrimines par les classes deja identifiees. Les nouvelles caracteristiques sont 
representees par une nouvelle classe, sous-classe d'une des classes existantes. 
La specialisation est une technique tres efficace pour l'extension coherente d'un 
ensemble de classes. 

L'exemple suivant montre une classification partielle des equipements de 
transmission, selon deux grandes families : les systemes continus et les systemes 
discrets. Les dispositifs concrets sont ajoutes dans la hierarchie par derivation du 
parent le plus proche. 
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Transmission 



Continue 



Discrete 




Variateur 




Derailleur 





BoTte de vitesses 



Extension par specialisation 



Figure 61 : Exemple d 'extension par specialisation. 



La generalisation et la specialisation sont deux points de vue antagonistes du 
concept de classification ; elles expriment dans quel sens une hierarchie de 
classes est exploitee. Dans toute application reelle, les deux points de vue sont 
mis en ceuvre simultanement. La generalisation est plutot employee une fois que 
les elements du domaine ont ete identifies afin de degager une description 
detachee des solutions. La specialisation, quant a elle, est a la base de la 
programmation par extension et de la reutilisation. Les nouveaux besoins sont 
encapsules dans des sous-classes qui etendent harmonieusement les fonctions 
existantes. 




Super-classe I 



I Sous-classe \ 

i r 



| Classe plus 
1 specialisee 
I 



| Classe plus 
— I generale 

I 



11 

I X 



Figure 62 : La generalisation et la specialisation offrent deux points de vue antagonistes sur 

une hierarchie de classes. 



L'elaboration d'une hierarchie de classes demande de la part des developpeurs 
des qualites et des competences differentes selon le point d'entree dans 
l'arborescence. L' identification des super-classes fait appel avant tout a la 
capacite d' abstraction, independamment de toutes connaissances techniques, 
alors que la realisation des sous-classes demande surtout une expertise 
approfondie d'un domaine particulier. 
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En fait, la situation est tout a fait paradoxale ! II est plutot difficile de trouver les 
super-classes, mais les programmes ecrits dans leurs termes sont plus simples a 
developper. II est assez facile de trouver les sous-classes, mais difficile de les 
realiser. 

La generalisation ne porte aucun nom particulier ; elle signifie toujours : est un ou 
est une sorte de. La generalisation ne concerne que les classes, elle n'est pas 
instanciable en liens et, de fait, ne porte aucune indication de multiplicite. Dans 
l'exemple suivant, le lion est une sorte de carnivore et il n'est pas possible pour 
un lion d'etre plusieurs fois un carnivore : un lion est un carnivore. 



Animal 



Carnivore 



Herbivore 



Lion 



Mouton 



Lapin 



Figure 63 : La generalisation ne porte ni nom particulier ni valeur de multiplicite. 

La generalisation est une relation non reflexive : une classe ne peut pas deriver 
d'elle-meme. 











1 



Impossible 



Figure 64 : La generalisation est une relation non reflexive. 



La generalisation est une relation non symetrique : si une classe B derive d'une 
classe A, alors la classe A ne peut pas deriver de la classe B. 
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Figure 65 : La generalisation est une relation non symetrique. 

La generalisation est par contre une relation transitive : si C derive d'une classe B 
qui derive elle-meme d'une classe A, alors C derive egalement de A. 



I 
I 



r~B > 



<; 

I 
I 
I 



! c 
i 



Figure 66 : La generalisation est une relation transitive. 



Des ensembles aux classes 

La notion de classe est tres proche de la notion d' ensemble. La specification 
d'une classe est une description abstraite, analogue a la description en 
comprehension d'un ensemble. Les objets instances d'une classe partagent des 
caracteristiques generales, exprimees dans la classe sous forme d'attribut, 
d'operation et de contrainte. 

Ces caracteristiques constituent la propriete caracteristique de F ensemble des 
instances. La propriete caracteristique d'un ensemble X est notee P (X). Dans les 
paragraphes suivants, le terme propriete caracteristique est applique directement 
a la classe et non a l'ensemble de ses instances. La figure suivante montre 
l'analogie entre une classe et un ensemble. 
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X 

Propriete caracteristique de X 




Figure 67 : Une classe donne une description abstraite d'un ensemble d'objets qui partagent 
des caracteristique s communes. 

L'ensemble Xpeut etre divise en sous-ensembles, afin de distinguer par exemple 
des particularites supplementaires partagees seulement par certains des elements 
de X. Le diagramme suivant montre deux sous-ensembles de X, les ensembles Y et 
Z. Les proprietes caracteristiques des ensembles Yet Z sont des extensions de la 
propriete caracteristique de X : 



P (X) c P(Y) et P (X) c P(Z) et P(Y)nP (Z) = P (X) 




Figure 68 : Les elements des ensembles Y et Z sont d'abord des elements de l'ensemble X. Les 
proprietes caracteristiques P (Y) et P ( Z) englobent la propriete caracteristique P(X). 

Les classes et les sous-classes sont 1' equivalent des ensembles et des sous- 
ensembles. La generalisation des classes correspond a la relation d'inclusion des 
ensembles. De ce fait, les objets instances d'une classe donnee sont decrits par la 
propriete caracteristique de leur classe, mais egalement par les proprietes 
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caracteristiques de toutes les classes parents de leur classe. Les sous-classes ne 
peuvent pas nier les proprietes caracteristiques de leurs classes parentes. La 
propriete caracteristique d'une sous-classe englobe la propriete caracteristique de 
toutes ses super-classes. Ce qui est vrai pour un objet instance d'une super- 
classe est vrai pour un objet instance d'une sous-classe. A l'image de l'inclusion 
dans les ensembles, la generalisation ordonne les objets au sein d'une hierarchie 
de classes. Le diagramme suivant montre qu'il existe deux sortes d' elements de X 
particuliers, respectivement decrits par les classes Y et Z. 



Figure 69 : La propriete caracteristique des sous-classes est une extension de la propriete 
caracteristique des super-classes. 

Le diagramme suivant illustre un exemple concret. II existe de tres nombreux 
livres ; certains s'adressent tout particulierement aux enfants, d'autres ont pour 
objectif I'enseignement. La classification n'est pas exhaustive : les livres qui ne 
s'adressent ni aux enfants, ni a I'enseignement ne sont pas distingues et 
appartiennent collectivement a la classe des livres. Les proprietes generales des 
livres, comme le nom de l'auteur ou le nombre de pages, sont definies dans la 
super-classe Livre. Chaque sous-classe reprend ces caracteristiques et peut en 
ajouter de nouvelles, comme la fourchette d'age des lecteurs dans le cas du livre 
pour enfants. 



Figure 70 : Les livres pour enfants et ceux pour I'enseignement reprennent les caracteristiques 

generales des livres. 
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La generalisation - sous sa forme dite multiple - existe egalement entre arbres de 
classes disjoints. Dans l'exemple suivant, laclasse Test issue de la combinaison 
des classes Yet Z. 



Figure 71 : Exemple de generalisation multiple a partir d' arbres de classes disjoints. 

Dans le monde des ensembles, la situation precedente correspond a 1' intersection 
de deux ensembles qui ne sont pas sous-ensembles du meme sur-ensemble. 



Figure 72 : Representation ensembliste de la generalisation multiple entre classes sans 

ancetre commun. 

Le diagramme suivant illustre une situation particulierement interessante. Les 
ensembles Y et Z partitionnent l'ensemble X, de sorte que les objets de 
1' ensemble X appartiennent forcement a l'un de ses sous-ensembles. La propriete 
caracteristique P (X) ne decrit pas directement les elements de X. P(X) est une 
description abstraite des elements de Yet Z obtenue par une factorisation operee 
sur P (Y) et P (Z). 
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Figure 73 : L' ensemble X est scinde en deux sous-ensembles disjoints Y et Z qui contiennent 
collectivement tous les objets de X. P (X) est une factorisation operee sur P(Y) et P( Z). 

Dans le monde des classes, la situation precedente met en jeu une classe 
abstraite, c'est-a-dire une classe qui ne donne pas directement des objets. Elle 
sert en fait de specification plus abstraite pour des objets instances de ses sous- 
classes. Le principal interet de cette demarche est de reduire le niveau de details 
dans les descriptions des sous-classes. Le nom d'une classe abstraite est en 
italique dans les diagrammes de classes. 



I 1 I Le nom des ^ 

j Classe abstraites j classes abstraites I 

i , ^ j lest en italique ' 

& c< 1 ' 

/ 

I *- "I r ^ n 

I Classe concrete A J Classe concrete B 



Figure 74 : Representation graphique d'une classe abstraite. 

Les classes abstraites facilitent 1' elaboration de logiciels generiques, facilement 
extensibles par sous-classement. L'ensemble des mecanismes qui servent de 
charpente pour les fonctions des applications est construit a partir des elements 
generaux fournis par les classes abstraites. Les specificites et les extensions sont 
encapsulees dans des sous-classes concretes. 

Dans les exemples precedents, les sous-ensembles Y et Z sont disjoints. Dans 
l'exemple suivant, l'intersection de Y et Z est non nulle et definit l'ensemble T. T 
regroupe l'ensemble des objets qui appartiennent a la fois a la classe Y et a la 
classe Z. T est simultanement sous-ensemble de Y et de Z. La propriete 
caracteristique de l'ensemble T est l'union des proprietes caracteristiques des 
ensembles Y et Z et de la propriete caracteristique de Tlui-meme. 
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Figure 75 : La propriete caracteristique de V ensemble T - intersection des ensembles Y et Z - 
contient V union des proprietes caracteristiques des ensembles Y et Z. 

En termes de classes, la situation precedente se represente de la maniere 
suivante : 



X 



Propriete caracteristique de X 




Propriete caracteristique de Y 





Propriete caracteristique de Z 




Propriete caracteristique de T 



Figure 76 : Exemple de generalisation en losange. Les objets instances de la classe T sont 
decrits simultanement par les classes X, Y, Z et T. 

Les objets de la classe T sont decrits une seule fois par la propriete 
caracteristique de X. Le nombre de branches de la generalisation n'est pas 
significatif pour la propagation des proprietes caracteristiques et ainsi T ne 
possede pas deux fois la propriete caracteristique de X. 

Les objets sont instances d'une classe ou ne le sont pas ; il n'est pas possible 
d'etre plusieurs fois instance de la meme classe. 
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De la difficulte de classer 

La classification n'est pas toujours une operation triviale. En effet, la 
determination des criteres de classification est difficile et dans certains cas il n'est 
pas possible de se determiner. En 1755, bien avant UML, Jean-Jacques Rousseau, 
dans 1' ouvrage Discours sur Vorigine et les fondements de I'inegalite parmi les 
homines, evoque le probleme de la classification dans les termes suivants : 

Chaque objet regut d'abord un nom particulier, sans egard aux genres et aux 
especes (...). Si un chine s'appelait A, un autre chene s'appelait B; car la 
premiere idee que Von tire de deux chose s, c'est qu'elles ne sont pas la meme ; 
et ilfaut souvent beaucoup de temps pour observer ce qu'elles ont de commun : 
de sorte que plus les connaissances etaient bornees, et plus le dictionnaire 
devint etendu. L'embarras de toute cette nomenclature ne put etre leve 
facilement, car, pour ranger les etres sous des denominations communes et 
generiques, il en fallait connaitre les proprietes et les differences ; ilfallait des 
observations et des definitions, c'est-a-dire de Vhistoire et de la metaphysique, 
beaucoup plus que les hommes de ce temps-Id n 'en pouvaient avoir. 

Les classifications doivent avant tout bien discriminer les objets. Les bonnes 
classifications sont stables et extensibles. II arrive qu'elles comportent des 
exceptions inclassables selon les criteres retenus. Le grand panda, par exemple, 
fait partie de la famille des ours alors que le petit panda est plus proche des ratons 
laveurs. L'ornithorynque appartient a la famille des mammiferes tout en etant 
ovipare. 

Les classifications s'effectuent selon des criteres dependant du point de vue. II 
n'y a done pas une classification, mais des classifications, chacune adaptee a un 
usage donne. 

Ainsi, pour les animaux, de nombreux criteres peuvent etre retenus : 

• la station, 

• le type de nourriture, 

• la protection. 

La determination des criteres pertinents et de l'ordre dans lequel ils doivent etre 
appliques n'est pas toujours facile. Une fois les criteres arretes, il faut les suivre 
de maniere coherente et uniforme selon l'ordre determine. 

L'ordre d'application des criteres est souvent arbitraire, et conduit a des 
decompositions covariantes qui se traduisent par des parties de modele 
isomorphes. 

Dans 1' exemple suivant, le critere de la station a ete applique avant le critere de la 
nourriture. Sans informations supplementaires, il est bien difficile de dire pourquoi 
ce choix a ete effectue. 
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Carnivore 



Covariance 



Figure 77 : Premiere forme de decomposition covariante. 

Les animaux peuvent tout aussi bien etre specialises d'abord par rapport a leur 
type de nourriture. 
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Herbivore 




Carnivore 



Bipede 



Quadrupede 
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Quadrupede 



Covariance 



Figure 78 : Deuxieme forme de decomposition covariante. 



En fait, aucune des solutions precedentes n'est satisfaisante, car le phenomene 
de covariance induit des points de maintenance multiples dans le modele. 

La generalisation multiple apporte une solution elegante pour la construction de 
classifications comportant des criteres independants, difficiles a ordonner. Les 
criteres independants determinent differentes dimensions de specialisation et les 
classes concretes sont obtenues par produit cartesien de ces differentes 
dimensions. 
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Figure 79 : Exemple de reduction de la covariance au moyen de la generalisation multiple. 

Dans certains cas, la covariance existe du fait meme de la nature du domaine de 
l'application. L' exemple suivant illustre ce propos : un pilote de moto d'enduro 
doit posseder une licence d'enduro et un pilote de moto de cross doit posseder 
une licence de cross. Cette forme de covariance n'est pas reductible car elle 
concerne deux hierarchies distinctes. 



0..* 



Pilote 



Moto 



0..* 



Licence 



Cross Enduro 



Covariance non reductible 



Cross Enduro 



Figure 80 : Exemple de covariance non reductible. 



Les classifications doivent egalement comporter des niveaux d' abstractions 
equilibres. Dans l'exemple suivant, la decomposition n'est pas effectuee de 
maniere homogene. Les deux premieres sous-classes specialisent selon la 
fonction du vehicule alors que la troisieme sous-classe correspond a une marque 
de moto. 
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Vehicule terrestre 




Voiture 



Camion 




Monet et Goyon 



Figure 81 : Exemple de classification desequilibree. 

L'enumeration de toutes les marques n'est pas non plus une bonne idee car cela 
cree enormement de sous-classes. II vaut mieux favoriser le critere le plus global 
car c'est lui qui donnera des sous-classes plus extensibles. En regie generate, il 
vaut mieux limiter le nombre de sous-classes a chaque niveau hierarchique, quitte 
a augmenter le nombre d'objets par classe et a se reserver les attributs d'objets 
pour qualifier finement les objets. 

La derive vers un trop grand nombre de classes est illustree dans l'exemple 
suivant. D'une part, le critere de la couleur est trop precis pour determiner une 
classe et d' autre part, il genere trop de classes. Enfin, du fait du lien statique entre 
classe et instance, le modele ne permet pas de changer la couleur d'une voiture ! 
II faut en fait que le critere de generation d'une classe soit statique. La couleur 
doit etre un attribut des vehicules, pas un critere de specialisation. 



Vehicule terrestre 



Voiture 




Voiture bleue 




Voiture rouge 



Voiture verte 



Figure 82 : Exemple de mauvais critere pour la determination des classes. 

La forme classique de la relation de generalisation de classes introduit un 
couplage statique tres fort dans le modele, non mutable, comme le lien entre un 
objet et sa classe. De ce point de vue, la generalisation n'est pas adaptee pour 
representer les metamorphoses. L'exemple suivant ne represente pas 
correctement le cas du papillon qui passe successivement du stade de chenille, au 
stade de chrysalide puis au stade de lepidoptere. 
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Figure 83 : Le modele ci-dessus n'est pas adapte pour representer les papillons, car la 
relation qui lie un objet a sa classe n'est pas mutable. 



La solution pour la representation des papillons consiste a sortir l'element 
mutable. Dans notre cas, l'apparence d'un papillon donne est traduite par un lien 
vers un objet specifique qui decrit son stade. 
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Figure 84 : Exemple d' extraction de l'element mutable. L'objet qui materialise l'apparence 
du papillon peut changer pendant son existence. 



L'approche generale pour dynamiser une classification consiste, comme dans le 
cas de la mutabilite, a extraire le ou les elements sujets a specialisation. Cette 
approche permet egalement la classification multiple, au moyen d'une multiplicite 
de valeur illimitee. 



Classe 
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Type B 



Type C 



Figure 85 : Forme generale de la classification dynamique. 



Le diagramme suivant montre un exemple de realisation d'une classification selon 
la forme precedente, mais sans generalisation. Sur chaque livre est collee une 
gommette dont la couleur permet par de distinguer le proprietaire ou de preciser la 
nature de l'ouvrage. 
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Figure 86 : Exemple de classification realisee par un systeme de gommettes de couleur. 

L' heritage 

II existe de nombreuses manieres de realiser la classification. En programmation 
objet, la technique la plus utilisee repose sur l'heritage entre classes. 

Principe general 

L'heritage est une technique offerte par les langages de programmation pour 
construire une classe a partir d'une ou plusieurs autres classes, en partageant des 
attributs, des operations et parfois des contraintes, au sein d'une hierarchie de 
classes. Les classes enfants heritent des caracteristiques de leurs classes 
parents ; les attributs et les operations declares dans la classe parent, sont 
accessibles dans la classe enfant, comme s'ils avaient ete declares localement. 

L'heritage est utilisee pour satisfaire deux besoins distincts : la classification et la 
construction. Cette ambivalence de la relation d'heritage, qui peut a la fois classer 
et construire, est la source de beaucoup d' incoherences de programmation. II en 
est de l'heritage comme de la conduite automobile ; il faut se tenir ni trap a droite 
ni trop a gauche, mais bien au milieu de la voie, sinon le risque d' accident est 
eleve. II faut apprendre a utiliser correctement l'heritage, comme il faut apprendre 
a conduire les voitures. 

En programmation, avec un langage objet comme C++, la classification se realise 
tres souvent par une relation d'heritage entre la classe plus general e et la classe 
plus specifique. L'heritage propage les caracteristiques de la classe parent dans 
les classes enfants, de sorte que plusieurs classes peuvent partager une meme 
description. De ce point de vue, l'heritage permet une description economique 
d'un ensemble de classes reliees par une relation de classification. 

De nombreux programmeurs effectuent un amalgame entre la notion de 
classification impliquee par l'heritage et la composition virtuelle qui en resulte. 
Ces programmeurs recherchent avant tout une economie d'expression a court 
terme ; ils ont pris l'habitude d'integrer des composants dans un compose en 
exploitant la propagation des caracteristiques realisee automatiquement par la 
relation d'heritage. La construction de composants par heritage est une technique 
de programmation parfaitement respectable, a condition de clairement materialiser 
le fait dans le programme. Lorsque le programmeur construit par heritage, il doit 
indiquer que la relation d'heritage concernee est utilisee pour la construction et 
non pour la classification. Le langage C++, par exemple, permet de distinguer 
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l'heritage pour la classification, de l'heritage pour la construction, par l'usage des 
mots-cles public et private. 

class True : private Parent_Pour_Construction, 
public Parent_Pour_Classification 

{ 

} ; 

Figure 87 : Distinction entre heritage pour la classification et heritage pour la construction. 

La distinction doit etre operee visuellement dans les diagrammes de classes, 
comme le montre l'exemple suivant : un semaphore n'est ni une liste chainee, ni 
un compteur, mais peut se construire a partir de ces deux composants. 



Liste chainee 




Semaphore 



Figure 88 : Representation graphique de l'heritage pour la construction. 

Cette distinction se fait essentiellement en conception ou, sauf indication 
contraire, l'heritage represente une relation de generalisation plutot qu'une 
relation de composition. 

L'heritage est entache de contingences de realisation et, en particulier, l'heritage 
n'effectue pas une union des proprietes caracteristiques des classes, mais plutot 
une somme de ces proprietes. Ainsi, certaines caracteristiques peuvent etre 
indument dupliquees dans les sous-classes. L'heritage multiple doit done etre 
manie avec beaucoup de precautions car les techniques de realisation de 
l'heritage peuvent induire des problemes de collision de noms lors de la 
propagation des attributs et des operations des classes parents vers les sous- 
classes. 

L'exemple suivant illustre un conflit de nom, consequence d'une relation 
d'heritage multiple realisee par copie. Les super-classes definissent toutes les 
deux un attribut A de sorte que la classe Z possede deux attributs A Si A 
represente exactement la meme notion dans les classes Xet Y, il n'y a pas de 
raison de propager deux attributs dans la sous-classe. En revanche, si A designe 
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deux proprietes differentes, il serait judicieux d'en renommer une afin de pouvoir 
les distinguer. II n'existe pas de reponse toute faite a ce probleme : les langages 
objet different dans leur maniere de le traiter. 
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A de X 
Ade Y 



Figure 89 : Exemple de collision de noms. Le nomAest defini dans les deux super-classes X 

et Y. 

Le conflit precedent apparait egalement dans les formes de generalisation en 
losange, a la difference pres qu'il n'y a vraiment pas de raisons de dupliquer 
l'attribut A dans la classe Z, etant donne que 1' attribut A est unique dans la classe 
T. Z est une sorte de T, et non plusieurs fois une sorte de T ! Ici aussi, chaque 
langage objet apporte sa propre reponse a ce type de probleme. 
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Figure 90 : Exemple de collision de noms dans le cas d'une forme d'heritage en losange. 



Cette situation est suffisamment ennuyeuse pour que certains langages objet, 
comme Java ou Ada 95, n'offrent pas d'heritage multiple. Dans la pratique, 
l'heritage multiple peut etre employe sans trop de soucis lorsque sa mise en 
oeuvre a accompagne 1' elaboration du modele depuis le debut. Par contre, il y a 
fort peu de chances pour que l'heritage multiple soit la maniere d'effectuer une 
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fusion entre deux ensembles de classes construits de maniere totalement 
independante. En conclusion : V usage de 1' heritage multiple doit etre anticipe ! 



Paquetage A 
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Figure 91 : L'heritage multiple n'est pas adapte pour la construction d'une classe par fusion 
de plusieurs classes issues de paquetages elabores de maniere independante. 

La delegation 

L'heritage n'est pas une necessite absolue et peut toujours etre remplace par la 
delegation. La delegation presente l'avantage de reduire le couplage dans le 
modele : d'une part, le client ne connait pas directement le fournisseur, et d'autre 
part, le fournisseur peut etre modifie en cours de route. Cette approche permet la 
mise en oeuvre de la generalisation multiple avec les langages qui ne possedent 
que l'heritage simple. Le diagramme suivant illustre le mecanisme de delegation ; 
le client communique avec une interface qui propage les questions a un ou 
plusieurs delegues. 
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Propagation j - 



Delegue 1 j 
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I 



Propagation 



I : Delegue 2 



Figure 92 : Exemple de mecanisme de delegation. L' interface decouple le client et les 

fournisseurs. 
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La delegation permet egalement de contourner le probleme de la covariance, 
evoque plus haut, au detriment toutefois de la propagation automatique des 
caracteristiques des super-classes vers les sous-classes. Le diagramme suivant 
illustre une construction a base de delegation qui peut remplacer la generalisation 
multiple. 
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Figure 93 : Exemple de reduction de la covariance par la delegation. 



Dans le systeme de fenetres X Window, plus precisement dans la couche des 
Intrinsics, 1' heritage est entierement simule a la main, grace a la mise en oeuvre de 
structures de donnees qui designent les structures de donnees des parents. Les 
diagrammes suivants illustrent l'exemple de Douglas A. Young 7 pour la realisation 
de l'heritage lors de la construction de widgets. 



Core 




Basic 

ignore : int 
foreground : in 
gc : GC 



Figure 94 : Exemple d' heritage entre widgets dans le systeme de fenetres X Window. 

Le systeme X Window est entierement realise en C, sans support direct pour 
l'heritage. Le diagramme suivant montre comment l'heritage est simule a la main, 
en incorporant une description de la classe parent CoreClassPart dans la 
classe derivee BasicClassRec. La classe BasicPart regroupe les variables 



7 Young D. A. 1990, The X Window System, Programming and Applications with 
Xt. Prentice Hall, Englewood Cliffs, New Jersey, pp 340-341. 
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d' instance et contient une reference vers la description de la classe 
BasicClassRec. 
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Figure 95 : Exemple de realisation de V heritage a la main par incorporation de la classe 
parent dans la classe derivee. 

Le principe de substitution 

La classification propage Fetat, le comportement et les contraintes. II n'y a pas de 
demi-mesure : toutes les proprietes de la classe parent sont valables integralement 
pour la classe enfant. Le besoin d'heriter partiellement est le signe que la relation 
d'heritage consideree ne realise pas vraiment une relation de classification. 

Le principe de substitution, enonce originellement par Liskow 8 , permet de 
determiner si une relation d'heritage est bien employee pour la classification. Le 
principe de substitution affirme que : 

il doit etre possible de substituer n'importe quel objet instance d'une sous- 
classe a n'importe quel objet instance d'une super-classe sans que la 
semantique du programme ecrit dans les termes de la super-classe ne soit 
ajfectee. 

L'illustration suivante montre un programme - symbolise par un rectangle - qui 
fait reference a des objets de la classe parent. Si le principe de substitution est 
verifie, tout objet instance de la classe CP doit pouvoir etre remplace par un objet 
instance de la classe CE, sans que cela n'affecte le programme ecrit dans les 
termes de la classe CP. 



8 Liskow B. 1987, Proceedings ofOOPSLA '87. ACM SIGPLAN Notices 23 (5), pp 
17-34. 
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Figure 96 : Illustration du principe de substitution. 



La notion de generalisation implique que la propriete caracteristique de la super- 
classe est incluse dans la propriete caracteristique de la sous-classe. Or, les 
compilateurs de certains langages ne sont pas capables de verifier integralement 
que cette condition est satisfaite dans le cas de l'heritage, car la syntaxe seule ne 
suffit pas toujours pour exprimer l'ensemble des proprietes. Les attributs et les 
operations sont propages automatiquement, mais les contraintes ne le sont pas 
necessairement. Souvent, une contrainte est traduite par une forme de code 
particuliere, implantee dans la realisation d'une operation. Comme les langages 
objet permettent la redefinition des operations dans les sous-classes, les 
programmeurs peuvent involontairement introduire des incoherences entre la 
specification d'une super-classe et la realisation dans une des sous-classes. Ces 
incoherences concernent principalement les contraintes exprimees de maniere 
programmed et non declarative. L' adherence au principe de substitution garantit 
qu'une relation d'heritage entre classes correspond bien a une generalisation. 
Malheureusement, la mise en oeuvre du principe de substitution est du ressort du 
programmeur et non du compilateur et, comme le programmeur est humain, il n'est 
pas a l'abri d'une erreur. Sans respect du principe de substitution, le 
polymorphisme decrit dans le paragraphe suivant ne peut etre mis en oeuvre. 

Le polymorphisme 

Le terme polymorphisme decrit la caracteristique d'un element qui peut prendre 
plusieurs formes, comme l'eau qui se trouve a l'etat solide, liquide ou gazeux. En 
informatique, le polymorphisme designe un concept de la theorie des types, selon 
lequel un nom d'objet peut designer des instances de classes differentes issues 
d'une meme arborescence. 

Principe general 

Les interactions entre objets sont ecrites selon les termes des specifications 
definies, non pas dans les classes des objets, mais dans leurs super-classes. 

Ceci permet d'ecrire un code plus abstrait, detache des particularismes de chaque 
classe, et d'obtenir des mecanismes suffisamment generaux pour etre encore 
valides dans le futur, quand seront crees de nouvelles classes. 
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Le terme polymorphisme designe dans ce cas particulier le polymorphisme 
d'operation, c'est-a-dire la possibilite de declencher des operations differentes en 
reponse a un meme message. Chaque sous-classe herite de la specification des 
operations de ses super-classes, mais a la possibilite de modifier localement le 
comportement de ces operations, afin de mieux prendre en compte les 
particularismes lies a un niveau d' abstraction donne. De ce point de vue, une 
operation donnee est polymorphe puisque sa realisation peut prendre plusieurs 
formes. 

Le polymorphisme est un mecanisme de decouplage qui agit dans le temps. Les 
benefices du polymorphisme sont avant tout recoltes durant la maintenance. Le 
polymorphisme n'influence pas l'analyse, mais depend de l'analyse : sa mise en 
oeuvre efficace repose sur l'identification de mecanismes abstraits, applicables de 
maniere uniforme a des objets instances de sous-classes differentes. II ne faut pas 
penser l'analyse en termes de polymorphisme, il faut penser l'analyse en termes 
d' abstraction et ainsi, par effet de bord benefique de cette abstraction, rendre 
possible le polymorphisme. 

Application 

Le diagramme suivant represente une collection polymorphe, le zoo. Le zoo 
contient de nombreux animaux qui peuvent etre soit des lions, soit des tigres, soit 
des ours. Le nom Animal, connu de la classe Zoo, decrit collectivement toutes 
les sortes d' animaux. Le logiciel, ecrit au niveau d'abstraction du zoo, n'a pas 
besoin de connaitre les details propres a chaque animal. 
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Figure 97 : Exemple de collection polymorphe. 

Les animaux de l'exemple precedent savent tous dormir, mais chaque race a ses 
habitudes particulieres. La specification de 1' animal dit que les animaux peuvent 
dormir. Les sous-classes particularisent l'operation Dormir () selon les gouts 
de chaque race. Le diagramme suivant montre comment chaque race d' animaux a 
1' habitude de dormir. 
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Figure 98 : Exemple de specialisation d'une operation. 

Les mecanismes generaux ecrits selon la specification du zoo n'ont pas besoin de 
connaitre les gouts particuliers de chaque genre d' animal pour invoquer 
l'operation Dormir () . Ainsi, le soir venu, le gardien se promene au travers du 
zoo et informe chaque animal qu'il est temps de dormir. 
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Figure 99 : Envoi du message Dormir () a tous les animaux du zoo. 

En termes plus informatiques, ceci revient a visiter la collection Zoo en utilisant 
eventuellement un iterateur, et a envoyer le message Dormir a chaque animal. 

Un iterateur est un objet associe a une collection qui permet d'en visiter tous ses 
elements sans en devoiler sa structure interne. 

L'iterateur est dit actif lorsque le controle de l'iteration est laisse a l'utilisateur, au 
moyen des quatre operations suivantes : 

• Initialiser qui permet de prendre en compte des elements presents a un 
instant donne dans la collection, 

• Suivant qui permet le passage a l'element suivant, 

• Vale ur qui retourne 1 ' element courant, 

• Termine qui est vrai lorsque tous les elements ont ete visites. 
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Figure 100 : Exemple d' iterateur actif. 

Le fragment de code suivant illustre l'usage d'un iterateur sur le zoo. 

La variable UnAnimal est polymorphe : elle peut contenir n'importe quel animal 
retourne par la fonction Visite . Valeur() . L'envoi du message Dormir () 
a 1' animal contenu par la variable UnAnimal declenche une maniere specif ique 
de dormir qui depend en fait de la sous-classe de 1' animal. 

Visite : Iterateur ; 

UnAnimal : Animal ; -- variable polymorphe 

Visite. Initialiser(leZoo); 
while not Visite.Termine() 
loop 

UnAnimal := Visite. Valeur () ; 
UnAnimal. Dormir(); 
Visite. Suivant(); 
end loop; 

Figure 101 : Exemple de code pour endormir tous les animaux du zoo. 

Le mecanisme qui endort les animaux du zoo est independant des animaux qui se 
trouvent reellement dans le zoo a un moment donne : l'effectif de chaque espece 
n'est pas inscrit dans l'algorithme qui se contente d' exploiter un iterateur sur une 
collection. Le mecanisme ne depend pas non plus de la sous-classe precise de 
l'animal courant : si de nouveaux animaux sont ajoutes dans le zoo, il n'est pas 
necessaire de modifier le code qui endort les animaux existants pour endormir les 
nouveaux arrivants. Les particularites des nouveaux animaux sont encapsulees 
dans leur classe qui est rajoutee dans le modele par derivation de la classe 
Animal deja existante. Pour prendre en compte un nouvel animal, il suffit done 
de creer une sous-classe, de realiser l'operation Dormir () dont il herite, et 
eventuellement de recompiler. 
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Figure 102 : Exemple de prise en compte d'un nouvel animal par ajout d'une sous-classe. 



La recherche automatique du code a executer est le fruit de la liaison dynamique. 
Dans les langages traditionnels comme Pascal, le choix d'une operation est une 
activite completement statique, effectuee a la compilation en fonction du type des 
variables. Dans les langages a liaison dynamique, le declenchement d'une 
operation requiert une activite durant l'execution pour retrouver la realisation de 
l'operation qui correspond au message recu. Sans liaison dynamique, le code 
precedent devrait etre transforme de la facon suivante : 



Visite : Iterateur ; 

UnAnimal : Animal ; -- variable polymorphe 



Visite. Initialiser(leZoo); 
while not Visite.Termine() 
loop 

UnAnimal := Visite. Valeur () ; 

case UnAnimal. Classe () 
when Lion 

-- Dormir sur le ventre 
When Tigre 

-- Dormir sur le dos 
When Ours 

-- Dormir dans un arbre 
When Paresseux 

-- Dormir sans fin 
end case; 



Visite. Suivant(); 
end loop; 
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Figure 103 : Sans liaison dynamique, le programmeur doit effectuer lui-meme le choix de 
V operation qui correspond au message Dormir ( ) . 

Cette solution sans liaison dynamique presente le desavantage d'introduire de 
nombreux points de maintenance dans le code. Chaque fois qu'un nouvel animal 
est ajoute dans le zoo, il faut ajouter une branche dans l'instruction case pour 
prendre en compte les specificites du nouvel arrivant. 

Le polymorphisme supprime ces points de maintenance et du meme coup reduit 
considerablement l'usage des instructions a branchements multiples dans les 
mecanismes qui n'ont pas besoin de connaitre explicitement la classe d'un objet. 
Les operations du type Class_Of, comme celle employee dans l'exemple 
precedent (case UnAnimal . Classe () ), qui retournent la classe d'un objet, 
doivent alors etre utilisees avec circonspection, car leur usage va a l'encontre du 
polymorphisme. Un mecanisme ecrit selon les termes d'une super-classe doit 
pouvoir ignorer les details precises dans les sous-classes. 

L'exemple precedent montre egalement qu'il est possible d'employer un langage a 
liaison statique plutot que dynamique apres une analyse objet, mais que V effort 
de realisation est superieur puisqu'il faut organiser manuellement le 
declenchement des operations. 

Exploitation du principe de substitution 

L'exemple precedent ne fonctionne que si chaque animal comprend le message 
Dormir () . Les mecanismes qui mettent en ceuvre le polymorphisme manipulent 
des objets au travers des specifications de leurs super-classes. Dans le cas d'un 
langage type, le compilateur peut verifier statiquement que les messages seront 
compris par un objet, soit parce qu'une operation est declaree dans la classe 
meme de l'objet, soit parce que cette operation est heritee d'une des super- 
classes. Cette verification syntaxique ne suffit toutefois pas a garantir un bon 
comportement polymorphe ; il faut en plus que les realisations des operations 
dans les sous-classes soient conformes aux specifications donnees dans les 
super-classes, en particulier aux contraintes qui les accompagnent. Pour que le 
polymorphisme fonctionne effectivement, il faut - au-dela de la syntaxe seule - 
que le principe de substitution soit verifie. 

L'exemple suivant illustre une violation du principe de substitution. Le 
programmeur decide de faire deriver l'autruche de l'oiseau pour obtenir les 
plumes et le bee, mais ne respecte pas la specification de l'operation Voler () 
en realisant un code qui ne fait pas voler l'autruche. 
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Figure 104 : Exemple de violation du principe de substitution. 

La malversation precedente ne porte pas a consequence tant que personne n'ecrit 
de mecanisme general pour manipuler les oiseaux. En revanche, des lors que des 
mecanismes generaux exploitent la specification de la classe Oiseau, par 
exemple pour faire s'envoler tous les types d'oiseaux en cas de danger, 
l'incoherence introduite dans la classe Autruche se traduit au mieux par une 
autruche qui se fait manger et au pire par la situation la plus catastrophique qui 
puisse arriver en application de la loi de Murphy. 

Le diagramme de collaboration suivant montre comment une petite autruche se 
fait manger par un gros chat ! 
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Figure 105 : Exemple de non respect du principe de substitution. La petite autruche ne se 
comporte pas comme un oiseau et se fait devorer par le gros chat. 
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Declenchement des operations 

Ce paragraphe a pour objectif de presenter les grandes lignes du mecanisme de 
liaison dynamique, independamment des particularites syntaxiques des langages 
de programmation. Les differentes etapes de l'exemple montrent les formes de 
declenchement d'une operation en fonction de la classe de l'objet qui recoit le 
message. 

Le diagramme de classes suivant decrit la hierarchie des classes qui sert de 
support a la discussion, et montre la definition et les realisations de l'operation Z 
qui sera declenchee. Les classes abstraites I et Jne sont pas instanciables. 
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Figure 106 : Exemple de hierarchie de classes. L'operation Z est definie dans la classe de 
base I, puis realisee dans la classe K et modifiee dans la classe M. 



Les objets de la classe Client possedent des liens polymorphes vers des 
objets des classes K, L ou M. 
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Figure 107 : Chaque objet de la classe Client peut communiquer avec quatre objets 
instances des classes concretes K, L ou M. 



Le lien Un_I est polymorphe et peut designer un objet instance d'une classe 
concrete derivee de I par exemple la sous-classe K. Le client peut ainsi manipuler 
un objet instance d'une sous-classe, au travers de la specification d'une super- 
classe. Toutes les caracteristiques de la super-classe s'appliquent aux objets 
instances des sous-classes, en particulier le message Z peut etre envoye a 
l'objet Un_K le long du lien polymorphe Un_I. 

Le code correspondant a l'operation Z est recherche a l'execution en descendant 
l'arbre d'heritage jusqu'a la classe precise de l'objet. La classe K realise 
l'operation Z, le message est compris et l'operation realisee dans la classe K est 
executee. 
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Figure 108 : Le lien Un_I designe un objet de la classe K. Le message est compris, car la 
classe K realise I 'operation Z. 

Le cas de figure suivant est proche du cas precedent, si ce n'est que la recherche 
s'effectue un cran plus bas dans la hierarchie. La classe L n'ayant pas modifie la 
realisation de l'operation Z heritee de la classe K, le meme comportement que 
precedemment est declenche. 
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Figure 109 : La realisation de I'operation Z presente dans la classe L est heritee de la classe 
K. A V execution, le comportement realise dans la classe K sera declenche. 



Toute classe intermediaire dans l'arborescence des classes peut fournir une 
specification pour manipuler les objets instances de ses sous-classes. A ce titre, 
le lien Un_L peut etre exploite de maniere polymorphe pour manipuler des objets 
instances de la classe M. Comme M modifie I'operation Z, l'expression Un_L . Z () 
declenche le code realise dans la classe M. 
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Figure 110 : Utilisation de la specification d'une classe de niveau intermediaire. 

La liaison dynamique n'est necessaire que pour rechercher automatiquement le 
code modifie dans les sous-classes et appele depuis la specification d'une super- 
classe. Lorsque la liaison dynamique n'est pas requise, les passages de messages 
peuvent etre avantageusement remplaces par de simples appels de procedures 
resolus statiquement. Les langages comme C++ ou Ada 95 autorisent le 
programmeur a choisir le type de liaison au coup par coup, operation par 
operation, selon les besoins. En Eiffel, le programmeur n'a pas a se soucier du 
choix de la liaison car le compilateur est suffisamment intelligent pour reconnaitre 
les liaisons qui seront toujours statiques. 

Dans l'exemple suivant, la liaison peut etre statique d'une part parce que le lien 
Un_K designe un objet de classe K et d' autre part parce que I'operation Z est 
realisee dans cette classe. 
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Figure 111 : Situation resoluble statiquement. 



Le code qui exploite le polymorphisme se caracterise par la quasi-absence 
d' instructions a branchements multiples (case, switch). Ceci est du au fait que 
les branchements sont realises de maniere implicite - en fonction de la classe de 
l'objet destinataire du message - lors de la recherche de I'operation a executer en 
reponse a la reception d'un message. 

Influence du typage 

Le polymorphisme existe dans les environnements types comme dans les 
environnements non types, mais seuls les environnements types garantissent 
une execution sans surprise des programmes - a condition toutefois de respecter 
le principe de substitution. La notion de typage permet au compilateur de verifier 
statiquement que les messages envoyes a un objet seront compris lors de 
l'execution. En Ada 95, en Eiffel, en C++ ou en Java, les messages sont toujours 
compris par le destinataire du fait du typage fort. En l'absence de typage fort, 
n'importe quel message peut etre envoye a n'importe quel objet. En Smalltalk, un 
message peut ne pas etre compris et l'expediteur doit done se preparer a cette 
eventualite. Ceci n'enleve rien a la vertu de la liaison dynamique, toujours utile 
pour trouver le code le plus adapte en fonction de la classe. Mais a la difference 
des langages types, la recherche peut etre infructueuse. 

II importe de ne pas confondre le polymorphisme avec la surcharge des 
operations, parfois appelee polymorphisme ad hoc. Certains langages autorisent 
l'emploi d'un meme nom pour designer une famille d'operations, avec un profil de 
parametres different pour chaque operation. La surcharge est un moyen elegant 
d'offrir la notion de signature variable, sans tomber dans le travers des operations 
a nombre de parametres variable comme en C. La surcharge est toujours resolue 
statiquement par les compilateurs, elle n' a rien a voir avec la liaison dynamique. 

Les heureux parents reconnaitront le comportement de leur progeniture dans la 
classe suivant. L'operation Manger () est surchargee : elle existe sous trois 
formes differentes, identifiables statiquement par le compilateur en fonction de la 
signature. 
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Figure 112 : Exemple d'une operation surchargee. La classe Enfant propose trois 
operations Manger ( ) differentes, identifiables statiquement par leur signature. 



3 

La notation UML 



La notation UML est une fusion des notations de Booch, OMT, OOSE et d'autres 
notations. UML est concue pour etre lisible sur des supports tres varies comme 
les tableaux blancs, le papier, les nappes de restaurants, les ecrans d'ordinateurs, 
les impressions en noir et blanc, etc. Les concepteurs de la notation ont recherche 
avant tout la simplicite ; UML est intuitive, homogene et coherente. Les symboles 
embrouilles, redondants ou superflus ont ete elimines en faveur d'un meilleur 
rendu visuel. 

UML se concentre sur la description des artefacts du developpement de logiciel, 
plutot que sur la formalisation du processus de developpement lui-meme : elle 
peut ainsi etre utilisee pour decrire les elements logiciels, obtenus par 
1' application de differents processus de developpement. UML n'est pas une 
notation fermee : elle est generique, extensible et configurable par l'utilisateur. 
UML ne recherche pas la specification a outrance : il n'y a pas une representation 
graphique pour tous les concepts imaginables ; en cas de besoins particuliers, 
des precisions peuvent etre apportees au moyen de mecanismes d'extension et de 
commentaires textuels. Une grande liberte est donnee aux outils pour le filtrage et 
la visualisation d'information. L'usage de couleurs, de dessins et d'attributs 
graphiques particuliers est laisse a la discretion de l'utilisateur. 

Ce chapitre propose un survol de la semantique des elements de modelisation 
d'UML, decrits de maniere precise dans le document UML 1.0, Semantics 9 . Cette 
presentation a pour objectif d'introduire les principaux concepts de modelisation 
et de montrer leur articulation au sein de la notation UML. Les elements de 
visualisation et les elements de modelisation sont presentes conjointement, en se 



9 Rational Software Corporation 1997, UML Semantics V 1.0. 
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servant de la notation comme d'un support pour faciliter la presentation de la 
semantique. 

UML definit neuf sortes de diagrammes pour representer les differents points de 
vue de modelisation. L'ordre de presentation de ces differents diagrammes ne 
reflete pas un ordre de mise en oeuvre dans un projet reel, mais simplement une 
demarche pedagogique qui essaie de minimiser les prerequis et les references 
croisees. 



Les diagrammes d'UML 



Un diagramme donne a l'utilisateur un moyen de visualiser et de manipuler des 
elements de modelisation. Les differents types de diagrammes d'UML sont 
presentes dans l'extrait du metamodele suivant. 
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Figure 113 : Differents types de diagrammes definis par UML. 

Un diagramme contient des attributs de placement et de rendu visuel qui ne 
dependent que du point de vue. La plupart des diagrammes se presentent sous la 
forme de graphes, composes de sommets et d'arcs. Les diagrammes contiennent 
des elements de visualisation qui representent des elements de modelisation 
eventuellement issus de paquetages distincts, meme en 1' absence de relations de 
visibilite entre ces paquetages 10 . 

Les diagrammes peuvent montrer tout ou partie des caracteristiques des elements 
de modelisation, selon le niveau de detail utile dans le contexte d'un diagramme 
donne. Les diagrammes peuvent egalement rassembler des informations liees 
entre elles, pour montrer par exemple les caracteristiques heritees par une classe. 

Voici, par ordre alphabetique, la liste des differents diagrammes : 



Car l'utilisateur peut tout voir ! 
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• les diagrammes d'activites qui representent le comportement d'une operation 
en termes d' actions, 

• les diagrammes de cas d' utilisation qui representent les fonctions du 
systeme du point de vue de l'utilisateur. 

• les diagrammes de classes qui representent la structure statique en termes de 
classes et de relations, 

• les diagrammes de collaboration qui sont une representation spatiale des 
objets, des liens et des interactions, 

• les diagrammes de composants qui representent les composants physiques 
d'une application, 

• les diagrammes de deploiement qui representent le deploiement des 
composants sur les dispositifs materiels, 

• les diagrammes d' etats -transitions qui representent le comportement d'une 
classe en terme d'etats, 

• les diagrammes d'objets qui representent les objets et leurs relations et 
correspondent a des diagrammes de collaboration simplifies, sans 
representation des envois de message, 

• les diagrammes de sequence qui sont une representation temporelle des 
objets et de leurs interactions. 

Les diagrammes de collaboration et les diagrammes de sequence sont tous deux 
appeles diagrammes d'interaction. Les diagrammes d'etats-transitions sont 
egalement appeles Statecharts' 1 , nom donne par leur auteur, David Harel. 



Concepts de base 



II est pratique de representer la semantique des elements de modelisation d'UML 
selon le formalisme d'UML. 

Ce type de representation recursive pose cependant le probleme de I 'oeuf et de la 
poule, principalement lors de l'apprentissage. C'est pourquoi il est conseille, en 
premiere lecture, de considerer les diagrammes comme des exemples de la 
notation, plutot que de chercher a approfondir leur comprehension 

Quoi qu'il en soit, les diagrammes montrent des vues simplifiees du metamodele 
afin de rendre le texte accessible au plus grand nombre de lecteurs. 



11 Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science 
of Computer Programming vol. 8. 



86 - Modelisation objet avec UML 



Les elements communs 

Les elements sont les briques de base d'UML. Les elements comprennent les 
elements de modelisation et les elements de visualisation. Les elements de 
modelisation representent les abstractions du systeme en cours de modelisation. 
Les elements de visualisation procurent des projections textuelles ou graphiques 
qui permettent la manipulation des elements de modelisation. 

Les elements sont regroupes en paquetages qui contiennent ou referencent les 
elements de modelisation. Un modele est une abstraction d'un systeme, 
represente par une arborescence de paquetages. 
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Figure 114 : Extrait du metamodele. Representation des deux grandes families d'elements qui 
forment le contenu des modeles. 



Les mecanismes communs 

UML definit un petit nombre de mecanismes communs qui assurent l'integrite 
conceptuelle de la notation. Ces mecanismes communs comprennent les 
stereotypes, les etiquettes, les notes, les contraintes, la relation de dependance et 
les dichotomies (type, instance) et (type, classe) . Chaque element 
de modelisation possede une specification qui contient la description unique et 
detaillee de toutes les caracteristiques de l'element. 

Les stereotypes, les etiquettes et les contraintes permettent l'extension d'UML. 
Les stereotypes specialisent les classes du metamodele, les etiquettes etendent 
les attributs des classes du metamodele et les contraintes etendent la semantique 
du metamodele. 
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Figure 115 : Extrait du metamodele. Representation des mecanismes communs. 



Les stereotypes 

Les stereotypes font partie des mecanismes d'extensibilite, prevus dans UML. 
Chaque element de modelisation d'UML a au plus un stereotype, lorsque la 
semantique de base de l'element est insuffisante. Un stereotype permet la 
metaclassification d'un element d'UML. II permet aux utilisateurs 
(methodologistes, constructeurs d'outils, analystes et concepteurs) d'ajouter de 
nouvelles classes d' elements de modelisation, en plus du noyau predefini par 
UML. Les stereotypes facilitent egalement l'unification de concepts proches, 
comme les sous-systemes ou les categories, qui sont exprimes au moyen de 
stereotypes de paquetage. 

Les stereotypes permettent l'extension controlee des classes du metamodele, par 
les utilisateurs d'UML. Un element specialise par un stereotype S est 
semantiquement equivalent a une nouvelle classe du metamodele, nommee elle 
aussi S. A 1' extreme, toute la notation aurait pu etre construite a partir des deux 
classes True et Stereotype, les autres concepts en derivant par stereotypage 
de la classe True. 

Les concepteurs d'UML ont recherche l'equilibre entre les classes incluses 
d'origine, et les extensions apportees par les stereotypes. Ainsi, seuls les 
concepts fondamentaux ont ete exprimes sous la forme de classes distinctes. Les 



88 - Modelisation objet avec UML 



autres concepts, derivables de ces concepts de base, ont ete traites comme des 
stereotypes. 

Les etiquettes 

Une etiquette est une paire (nom, valeur) qui decrit une propriete d'un 
element de modelisation. Les proprietes permettent l'extension des attributs des 
elements du metamodele. Une etiquette modifie la semantique de 1' element qu'elle 
qualifie. 

Les notes 

Une note est un commentaire attache a un ou plusieurs elements de modelisation. 
Par defaut, les notes ne vehiculent pas de contenu semantique. Toutefois, une 
note peut etre transformee en contrainte au moyen d'un stereotype, et dans ce 
cas, elle modifie la semantique des elements de modelisation auxquels elle est 
attachee. 

Les contrainte s 

Une contrainte est une relation semantique quelconque entre elements de 
modelisation. UML ne specifie pas de syntaxe particuliere pour les contraintes, 
qui peuvent ainsi etre exprimees en langage naturel, en pseudo-code, par des 
expressions de navigation ou par des expressions mathematiques. 

La relation de dependance 

La relation de dependance definit une relation d' utilisation unidirectionnelle entre 
deux elements de modelisation, appeles respectivement source et cible de la 
relation. Les notes et les contraintes peuvent egalement etre source d'une relation 
de dependance. 

Dichotomies (type, instance) et (type, classe) 

De nombreux elements de modelisation presentent une dichotomie (type, 
instance) , dans laquelle le type denote l'essence de l'element, et l'instance 
avec ses valeurs correspond a une manifestation de ce type. 

De meme, la dichotomie (type, classe) correspond a la separation entre la 
specification d'un element qui est enonce par le type et la realisation de cette 
specification qui est fournie par la classe. 

Les types primitifs 

Les types primitifs regroupent toutes les abstractions situees en marge d'UML. 
Ces types elementaires ne sont pas des elements de modelisation et ne possedent 
done ni stereotypes, ni etiquettes, ni contraintes. 
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Figure 116 : Extrait du metamodele. Representation des types primitifs d'UML. 

Les types suivants forment les types primitifs d'UML : 

• Booleen. Un booleen est un type enumere qui comprend les deux valeurs 
Vrai et Faux. 

• Expression. Une expression est une chaine de caracteres dont la syntaxe est 
hors de la portee d'UML. 

• Liste. Une liste est un conteneur dont les parties sont ordonnees et peuvent 
etre indexees. 

• Multiplicity. Une multiplicite est un ensemble non vide d'entiers positifs, 
etendu par un lexeme particulier, le caractere *, qui signifie que la multiplicite 
est illimitee. La syntaxe de la multiplicite est donnee par la regie suivante : 

multiplicite ::= [intervalle / nombre] 



intervalle ::= nombre " .. " nombre 

nombre ::= nombre_positif / nom / 

• Nom. Un nom est une chaine de caracteres qui permet de designer un element. 
Des noms composes peuvent etre formes a partir de noms simples, selon la 
regie suivante : 

nom_compose ::= nom_simple { '.' nom_compose } 

Le nom d'un element peut etre qualifie par le nom du paquetage qui le contient 
ou qui le reference, selon la syntaxe suivante : 

nom_qualifie ::= qualificateur nom_simple 
qualificateur ::= nom_de_paquetage 



• Point. Un point est un tuple (x, y, z) qui decrit une position dans 
l'espace. Par defaut, la composante z prend la valeur 0. 



{ \ 



' multiplicite} 



{ 



qualificateur } 



90 - Modelisation objet avec UML 



• Chaine. Une chaine est une suite de caracteres, designee par un nom. 

• Temps. Un temps est une chaine qui represente un temps absolu ou relatif et 
dont la syntaxe est hors de la portee d'UML. 

• Non-interprete. Un non-interprete est un true 12 dont la signification depend 
du domaine. 



Les paquetages 

Les paquetages offrent un mecanisme general pour la partition des modeles et le 
regroupement des elements de modelisation. Chaque paquetage est represente 
graphiquement par un dossier. 



Nom de 
paquetage 



Figure 117 : Representation des paquetages. 



Les paquetages divisent et organisent les modeles de la meme maniere que les 
repertoires organisent les systemes de fichiers. Chaque paquetage correspond a 
un sous-ensemble du modele et contient, selon le modele, des classes, des objets, 
des relations, des composants ou des nceuds, ainsi que les diagrammes associes. 

La decomposition en paquetages n'est pas l'amorce d'une decomposition 
fonctionnelle ; chaque paquetage est un regroupement d' elements selon un 
critere purement logique. La forme generale du systeme (1' architecture du 
systeme) est exprimee par la hierarchie de paquetages et par le reseau de relations 
de dependance entre paquetages. 

Les stereotypes «Categorie» et «Sous-systeme» permettent de 
distinguer, si besoin est, les paquetages de la vue logique et les paquetages de la 
vue de realisation (ces vues sont detaillees dans le quatrieme chapitre). 



Cat 

<l<Categorie>: ■ 



«Sous 



Sub 
system 



Figure 118 : Les paquetages peuvent etre stereotypes, pour distinguer par exemple les 
categories de la vue logique et les sous-systemes de la vue de realisation. 



UML parle de blob. 
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Un paquetage definit un espace de nom, de sorte que deux elements differents, 
contenus par deux paquetages differents, peuvent porter le meme nom. 

Un paquetage peut contenir d'autres paquetages, sans limite du niveau 
d'emboitement. Un niveau donne peut contenir un melange de paquetages et 
d'autres elements de modelisation, de la meme maniere qu'un repertoire peut 
contenir des repertoires et des fichiers. 



Figure 119: Exemple de representation mixte. Un paquetage contient des elements de 
modelisation, accompagnes eventuellement d'autres paquetages. 

Chaque element appartient a un paquetage. Le paquetage de plus haut niveau est 
le paquetage racine de l'ensemble d'un modele. Une classe contenue par un 
paquetage peut egalement apparaitre dans un autre paquetage sous la forme d'un 
element importe, au travers d'une relation de dependance entre paquetages. 

Les imports entre paquetages se represented dans les diagrammes de classes, les 
diagrammes de cas d'utilisation et les diagrammes de composants, au moyen 
d'une relation de dependance stereotypee, orientee du paquetage client vers le 
paquetage fournisseur. 



Fournisseur 



«lrppDrt» 



Figure 120 : Representation des imports entre deux paquetages au moyen d'une relation de 

dependance stereotypee. 
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Une relation de dependance entre deux paquetages signifie qu'au moins une 
classe du paquetage client utilise les services offerts par au moins une classe du 
paquetage fournisseur. Toutes les classes contenues par un paquetage ne sont 
pas necessairement visibles de l'exterieur du paquetage. 

L'operateur : : permet de designer une classe definie dans un contexte different 
du contexte courant. L'expression Zoo: : Kangourou designe la classe 
Kangourou definie dans le paquetage Zoo. 

Un paquetage est un regroupement d' elements de modelisation, mais aussi une 
encapsulation de ces elements. A l'image des classes, les paquetages possedent 
une interface et une realisation. Chaque element contenu par un paquetage 
possede un parametre qui signale si l'element est visible ou non a l'exterieur du 
paquetage. Les valeurs prises par le parametre sont: public ou 
Implementation (prive). 

Dans le cas des classes, seules celles indiquees comme publiques apparaissent 
dans 1' interface du paquetage qui les contient ; elles peuvent alors etre utilisees 
par les classes membres des paquetages clients. Les classes de realisation ne 
sont utilisables qu'au sein du paquetage qui les contient. 

Classe h 
exportee | 

U , 

isseur 

•y 

Realisation 



1 






Client ■ — 






> 





Figure 121 : Seules les classes exportees sont visibles a l'exterieur des paquetages. 

Les relations de dependance entre paquetages entrainent des relations 
d' obsolescence entre les elements de modelisation contenus dans ces 
paquetages. 

Pour des raisons de compilation lors de la realisation, il est fortement conseille 
que les dependances entre paquetages ne forment que des graphes acy cliques. II 
faut done eviter la situation suivante : 




Figure 122 : Exemple de dependance circulaire entre paquetages, d eviter. 
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De meme, il convient d'eviter les dependances circulaires transitives, illustrees ci- 
dessous : 




Figure 123 : Exemple de dependance circulaire transitive, a eviter. 



En regie generale, les dependances circulaires peuvent etre reduites en eclatant 
un des paquetages incrimines en deux paquetages plus petits, ou en introduisant 
un troisieme paquetage intermediaire. 

Certains paquetages sont utilises par tous les autres paquetages. Ces paquetages 
regroupent par exemple des classes de base comme des ensembles, des listes, des 
files, ou encore des classes de traitement des erreurs. Ces paquetages possedent 
une propriete qui les designe comme paquetages globaux. II n'est pas necessaire 
de montrer les relations de dependances entre ces paquetages et leurs utilisateurs 
ce qui limite la charge graphique des diagrammes. 



IHM 



Metier 



Erreur 

global 



Persistance 



Com 



Figure 124 : Afin de reduire la charge graphique, les dependances envers les paquetages 
visihles globalement ne sont pas portees dans les diagrammes. 
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Les diagrammes de classes 



Les diagrammes de classes expriment de maniere generale la structure statique 
d'un systeme, en termes de classes et de relations entre ces classes. De meme 
qu'une classe decrit un ensemble d'objets, une association decrit un ensemble de 
liens ; les objets sont instances des classes et les liens sont instances ces 
relations. Un diagramme de classes n'exprime rien de particulier sur les liens d'un 
objet donne, mais decrit de maniere abstraite les liens potentiels d'un objet vers 
d'autres objets. 



Classe 



Re lie 



< Instance de 



Objet 



r Relation < Instance de 



Re lie 



Lien 



Diagramme de classes Diagramme d'objets 



Figure 125 : Extrait du metamodele. Les diagrammes de classes representent les classes et les 

relations. 



Les classes 

Les classes sont representees par des rectangles compartimentes. Le premier 
compartiment contient le nom de la classe. Le nom de la classe doit permettre de 
comprendre ce que la classe est, et non ce qu'elle fait. Une classe n'est pas une 
fonction, une classe est une description abstraite - condensee - d'un ensemble 
d'objets du domaine de l'application. Les deux autres compartiments contiennent 
respectivement les attributs et les operations de la classe. 



Nom de classe 



Figure 126 : Representation graphique des classes. 



Une classe contient toujours au moins son nom. Lorsque le nom n'a pas encore 
ete trouve, ou n'est pas encore arrete, il est conseille de faire figurer un nom 
generique facile a identifier, comme A_Definir. Les compartiments d'une 
classe peuvent etre supprimes lorsque leur contenu n'est pas pertinent dans le 
contexte d'un diagramme. La suppression des compartiments reste purement 
visuelle, elle ne signifie pas qu'il n'y a pas d'attribut ou d'operation. 
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Norn de classe 



Figure 127 : Representation graphique simplifiee par suppression des compartiments. 

Le rectangle qui symbolise la classe peut egalement contenir un stereotype et des 
proprietes. UML definit les stereotypes de classe suivants : 

• «s±gnal», une occurrence remarquable qui declenche une transaction 
dans un automate, 

• «interface», une description des operations visibles, 

• «metaclasse», la classe d'une classe, comme en Smalltalk, 

• «utilitaire», une classe reduite au concept de module et qui ne peut 
etre instanciee. 

Les proprietes designent toutes les valeurs attachees a un element de 
modelisation, comme les attributs, les associations et les etiquettes. Une etiquette 
est une paire (attribut, valeur) definie par l'utilisateur ; elle permet de 
preciser par exemple des informations de generation de code, d'identification ou 
de references croisees. 



Nom de classe 

«Stereotype» 
Propriete 



Vehicule 
«Utilitaire» 
Etat = teste 
Auteur = pam 



Figure 128 : Les compartiments de classes peuvent contenir un stereotype et des proprietes, 
definis librement par l'utilisateur. 

Les attributs et les operations 

Les attributs et les operations peuvent etre montres de maniere exhaustive ou non 
dans les compartiments des classes. Par convention, le premier compartiment 
contient les attributs et le deuxieme compartiment contient les operations. 



Nom de classe 



Nom : type = valeur initiale 
Nom( ) 



Figure 129 : Visualisation des attributs et des operations dans les compartiments de la classe. 

La syntaxe retenue pour la description des attributs est la suivante : 
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Nom_Attribut : Type_Attribut = Valeur_Initiale 

Cette description peut etre completee progressivement, lors de la transition de 
1' analyse vers la conception. 

II arrive que des proprietes redondantes soit specifiers lors de 1' analyse des 
besoins. Les attributs derives offrent une solution pour allouer des proprietes a 
des classes, tout en indiquant clairement que ces proprietes sont derivees 
d'autres proprietes deja allouees. Dans l'exemple suivant, la classe Rectangle 
possede un attribut Longueur, un attribut Largeur, ainsi qu'un attribut 
derive Surface, qui peut etre construit a partir des deux autres attributs. 



Rectangle 

Longueur 

Largeur 

/Surface 



Figure 130 : Exemple d'attribut derive. La surface d'un rectangle peut etre determinee a 
partir de la longueur et de la largeur. 

Par la suite, en conception, l'attribut derive /Surface sera transforme en une 
operation Surface () qui encapsulera le calcul de surface. Cette transformation 
peut toutefois etre effectuee sans attendre, des lors que la nature derivee de la 
propriete surface a ete detectee. 



Rectangle 

Longueur 
Largeur 

Surface( ) 



Figure 131 : Transformation de l'attribut derive en une operation de calcul de la surface. 

La syntaxe retenue pour la description des operations est la suivante : 
Nom_ Opera tion 

(Nom_Argument : Type_Argument = Valeur_Par_Defaut, . . .) 
: Type_Retourne 

Toutefois, etant donne la longueur de la specification, les arguments des 
operations peuvent etre supprimes dans les graphiques. 

Visibility des attributs et des operations 

UML definit trois niveaux de visibilite pour les attributs et les operations : 

• public qui rend l'element visible a tous les clients de la classe, 

• protege qui rend l'element visible aux sous-classes de la classe, 
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• prive qui rend l'element visible a la classe seule. 

L' information de visibilite ne figure pas toujours de maniere explicite dans les 
diagrammes de classes, ce qui ne veut pas dire que la visibilite n'est pas definie 
dans le modele. Par defaut, le niveau de visibilite est symbolise par les caracteres 
+, # et -, qui correspondent respectivement aux niveaux public, protege et 
prive. 

Certains attributs et certaines operations peuvent etre visibles globalement, dans 
toute la portee lexicale de la classe. Ces elements, egalement appeles variables et 
operations de classe, sont representes comme un objet par un nom souligne. La 
notation se justifie par le fait qu'une variable de classe apparait comme un objet 
partage par les instances d'une classe. Par extension, les operations de classe 
sont aussi soulignees. 



+Attribut public 
#Attribut protege 
-Attribut prive 
Attribut de classe 



+Operation publiquef ) 
#Operation protegeef 
-Operation priveef ) 
Operation de classe( ) 



Figure 132 : Representation des different s niveaux de visibilite des attributs et des operations. 

Les interfaces 

Une interface utilise un type pour decrire le comportement visible d'une classe, 
d'un composant (decrits plus loin dans l'ouvrage) ou d'un paquetage. Une 
interface est un stereotype d'un type. UML represente les interfaces au moyen de 
petits cercles relies par un trait a l'element qui fournit les services decrits par 
1' interface. 



Une classe 



Una interface 



Figure 133 : Representation d'une interface au moyen d'un petit cercle relie a la classe qui 
fournit effectivement les services. 



Les interfaces peuvent egalement se representer au moyen de classes 
stereotypees. 
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Une classe 



«lnterface>; 
Vue A 



«lnterface>; 
Vue B 



Un utilisateur 



Un autre utilisateur 



Figure 134 : Exemple de representation des interfaces au moyen de classes stereotypies. 

Une interface fournit une vue totale ou partielle d'un ensemble de services offerts 
par un ou plusieurs elements. Les dependants d'une interface utilisent tout ou 
partie des services decrits dans l'interface. 

Les classes parametrables 

Les classes parametrables sont des modeles de classes. Elles correspondent aux 
classes generiques d'Eiffel et aux templates de C++. Une classe parametrable ne 
peut etre utilisee telle quelle. II convient d'abord de l'instancier, afin d'obtenir une 
classe reelle qui pourra a son tour etre instanciee afin de donner des objets. Lors 
de l'instanciation, les parametres effectifs personnalisent la classe reelle obtenue a 
partir de la classe parametrable. Les classes parametrables permettent de 
construire des collections universelles, typees par les parametres effectifs. 





1 
I 
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Classe gen 


erigue 







Figure 135 : Representation graphique des classes parametrables. 

Ce type de classes n'apparait generalement pas en analyse, sauf dans le cas 
particulier de la modelisation d'un environnement de developpement. Les classes 
parametrables sont surtout utilisees en conception detaillee, pour incorporer par 
exemple des composants reutilisables. La figure suivante represente 
l'instanciation d'une table generique, pour realiser un annuaire de personnes. Le 
parametre generique formel apparait dans le rectangle pointille de la classe 
parametrable alors que le parametre generique effectif est accole au nom de la 
classe obtenue par instanciation. L'instanciation est materialisee par une fleche 
pointillee, orientee de l'instance vers la classe parametrable. 
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Figure 136 : Exemple de representation de I'instanciation d'une classe parametrable. 

Les classes utilitaires 

II est parfois utile de regrouper des elements (les fonctions d'une bibliotheque 
mathematique par exemple) au sein d'un module, sans pour autant vouloir 
construire une classe complete. La classe utilitaire permet de representer de tels 
modules et de les manipuler graphiquement comme les classes conventionnelles. 

Les classes utilitaires ne peuvent pas etre instanciees car elles ne sont pas des 
types de donnees. II ne faut pas pour autant les confondre avec les classes 
abstraites qui ne peuvent pas etre instanciees car elles sont des specifications 
pures (voir le paragraphe qui traite de la generalisation). En C++, une classe 
utilitaire correspond a une classe qui ne contient que des membres statiques 
(fonctions et donnees). 

Le stereotype «Ut±lita±re>> specialise les classes en classes utilitaires. 
UML propose egalement une representation graphique alternative, avec une 
bordure grisee. 



Math 



Figure 137 : Exemple de representation graphique d'une classe utilitaire. 

Les associations 

Les associations representent des relations structurelles entre classes d'objets. 
Une association symbolise une information dont la duree de vie n'est pas 
negligeable par rapport a la dynamique generale des objets instances des classes 
associees. La plupart des associations sont binaires, c'est-a-dire qu'elles 
connectent deux classes. Les associations se representent en trafant une ligne 
entre les classes associees. 



«Utilitaire» 
Math 
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Figure 138 : Les associations se representent en tragant line ligne entre les classes associees. 

Les associations peuvent etre representees par des traits rectilignes ou obliques, 
selon les preferences de l'utilisateur. L'usage recommande de se tenir le plus 
possible a un seul style de representation des traits afin de simplifier la lecture 
des diagrammes au sein d'un projet. 
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Figure 139 : Les associations peuvent etre representees par des traits rectilignes ou obliques 
selon les preferences de l'utilisateur. 



Arite des associations 

La plupart des associations sont dites binaires car elles relient deux classes. Des 
arites superieures peuvent cependant exister et se representent alors au moyen 
d'un losange sur lequel arrivent les differentes composantes de 1' association. 



bluiJianl 



Salle 



Cours 



Dsibut 
Fin 



Enseignant 



Figure 140 : Exemple de relation ternaire qui materialise un cours. 



Les associations n-aires peuvent generalement se representer en promouvant 
1' association au rang de classe et en ajoutant une contrainte qui exprime que les 
multiples branches de l'association s'instancient toutes simultanement, en un 
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meme lien. Dans l'exemple suivant, la contrainte est exprimee au moyen d'un 
stereotype qui precise que la classe Cours realise une association ternaire. 
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Debut 
Fin 









Figure 141 : Representation d'une association ternaire au moyen d'une classe avec 

stereotype. 



Comme pour les associations binaires, les extremites d'une association n-aire sont 
appelees roles et peuvent porter un nom. La difficulte de trouver un nom different 
a chaque role d'une association n-aire est souvent le signe d'une association 
d'arite inferieure. 

Nommage des associations 

Les associations peuvent etre nominees ; le nom de 1' association apparait alors en 
italique, au milieu de la ligne qui symbolise 1' association, plus precisement 
dessus, au-dessus ou au-dessous. 



A 


Nom 


B 









Figure 142 : Les associations peuvent etre nommees afin de faciliter la comprehension des 

modeles. 



Sans en faire une regie systematique, l'usage recommande de nommer les 
associations par une forme verbale, soit active comme travaille pour, soit passive 
comme est employe par. 



Personne 


Travaille pour 


Societe 









Figure 143 : Nommage d'une association par une forme verbale active. 



Personne 


Est employee par 


Societe 









Figure 144 : Nommage d'une association par une forme verbale passive. 
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Dans les deux cas, le sens de lecture du nom peut etre precise au moyen d'un 
petit triangle dirige vers la classe designee par la forme verbale et place a 
proximite du nom de 1' association. 

Dans un but de simplification, le petit triangle peut etre remplace par les signes < 
et >disponibles dans toutes les fontes. 



Societe 


<Travaille pour 


Personne 









Figure 145 : Precision du sens d' application du nom d'une association. 

Les associations entre classes expriment principalement la structure statique ; de 
ce fait, le nommage par des formes verbales qui evoquent plutot le comportement 
se trouve un peu en porte-a-faux avec 1' esprit general des diagrammes de classes. 
Le nommage des extremites des relations permet de clarifier les diagrammes, 
comme le nommage des associations, mais d'une maniere plus passive, plus en 
phase avec la tonalite statique des diagrammes de classes. 

Nommage des roles 

L'extremite d'une association est appelee role. Chaque association binaire 
possede deux roles, un a chaque extremite. Le role decrit comment une classe voit 
une autre classe au travers d'une association. Un role est nomme au moyen d'une 
forme nominale. Visuellement, le nom d'un role se distingue du nom d'une 
association, car il est place pres d'une extremite de l'association etre en italique. 



Societe 


Employeur 


Personne 










Employe 





Figure 146 : Le nommage des roles exprime comment une classe voit une autre classe au 
travers d'une association. Dans I'exemple ci-dessus, la personne voit la societe comme son 
employeur, et la societe voit la personne comme son employe. 

Le nommage des associations et le nommage des roles ne sont pas exclusifs l'un 
de l'autre ; toutefois, l'usage melange rarement les deux constructions. II est 
frequent de commencer par decorer une association par un verbe, puis de se 
servir plus tard de ce verbe pour construire un substantif verbal qui nomme le role 
qui convient. 

Lorsque deux classes sont reliees par une seule association, le nom des classes 
suffit souvent a caracteriser le role ; le nommage des roles prend tout son interet 
lorsque plusieurs associations relient deux classes. Dans ce cas, il n'y a aucune 
correlation par defaut entre les objets qui participent aux deux relations. Chaque 
association exprime un concept distinct. Dans I'exemple suivant, il n'y a pas de 
relation entre les passagers et le pilote. 
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Passagers 



Figure 147 : Exemple d' associations multiples entre un avion et des personnes. 

La presence d'un grand nombre d' associations entre deux classes peut etre 
suspecte. Chaque association augmente le couplage entre les classes associees 
et un fort couplage peut etre le signe d'une mauvaise decomposition. II est 
egalement frequent que les debutants visualisent plusieurs fois la meme 
association en nommant chaque association avec le nom d'un des messages qui 
circulent entre les objets instances des classes associees. 
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Cunduiiv 






Berrmrret — 

Lavor 




AnQlui 



Figure 148 : Exemple de confusion entre association et messages. Une seule association est 
suffisante pour permettre a une personne de conduire, demarrer, laver et arreter sa voiture. 

Multiplicity des associations 

Chaque role d'une association porte une indication de multiplicite qui montre 
combien d'objets de la classe considered peuvent etre lies a un objet de 1' autre 
classe. La multiplicite est une information portee par le role, sous la forme d'une 
expression entiere bornee. 



1 


Un et un seul 


0..1 


Zero ou un 


M..N 


De M a N (entiers 
naturels) 


* 


De zero a plusieurs 


0..* 


De zero a plusieurs 


1..* 


D'un a plusieurs 



Figure 149 : Valeurs de multiplicite conventionnelles. 
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L'exemple suivant montre que plusieurs personnes travaillent pour une meme 
societe. La multiplicite de valeur 1 du cote de la classe Societe n'est pas tres 
realiste car elle signifie que toutes les personnes ont un emploi. La multiplicite de 
valeur 0 . . * du cote de la classe Personne signifie qu'une societe emploie de 
zero a plusieurs personnes. 
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1 Employe 





Figure 150 : Ce modele supprime le chomage ! Chaque personne travaille pour une societe, 
chaque societe emploie de zero a plusieurs personnes. 

Une valeur de multiplicite superieure a 1 implique une collection d'objets. Cette 
collection n'est pas bornee dans le cas d'une valeur *, qui signifie que plusieurs 
objets participent a la relation, sans prejuger du nombre maximum d'objets. Le 
terme collection, plus general que liste ou ensemble, est employe afin d'eviter 
toute supposition sur la structure de donnees qui contient les objets. 

Les valeurs de multiplicite expriment des contraintes liees au domaine de 
l'application, valables durant toute l'existence des objets. Les multiplicites ne 
doivent pas etre considerees durant les regimes transitoires, comme lors de la 
creation ou de la destruction des objets. Une multiplicite de valeur 1 indique 
qu'en regime permanent, un objet possede obligatoirement un lien vers un autre 
objet ; pour autant, il ne faut pas essayer d'en deduire le profil de parametres des 
constructeurs et systematiquement prevoir un parametre de la classe de l'objet lie. 
Les valeurs de multiplicite n'impliquent rien de particulier sur l'ordre de creation 
des objets. L'exemple suivant montre deux classes connectees par une 
association de multiplicite 1 vers 1, sans rien supposer sur le profil de parametres 
des constructeurs d'objets. Dans l'exemple suivant, il n'est pas necessaire de 
disposer d'une voiture pour construire un moteur et inversement. 



Voiture 




Moteur 




1 1 





Figure 151 : La multiplicite d'une association est le reflet d'une contrainte du domaine. 

La determination de valeurs de multiplicite optimales est tres importante pour 
trouver le bon equilibre, d'une part, entre souplesse et possibilite d'extension, et 
d'autre part, entre complexite et efficacite. En analyse, seule la valeur de la 
multiplicite est reellement importante. En revanche, en conception, il faut choisir 
des structures de donnees (pile, file, ensemble...) pour realiser les collections qui 
correspondent aux multiplicites de type 1 . . * ou 0 . .*. La surestimation des 
valeurs de multiplicite induit un surcout en taille de stockage et en vitesse de 
recherche. De meme, une multiplicite qui commence a zero implique que les 
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diverses operations doivent contenir du code pour tester la presence ou 
l'absence de liens dans les objets. 

Les valeurs de multiplicite sont souvent employes pour decrire maniere generique 
les associations. Les formes les plus courantes sont les associations 1 vers 1, 1 
vers Wet W vers N representees dans la figure suivante. 



A 


1 1 vers 1 


B 


1 vers N 

1 


t N vers N 





Figure 152 : Description generique des associations selon les valeurs de multiplicite. 



Placement des attributs selon les valeurs de multiplicite 

La reification des associations prend tout son interet pour les associations N vers 
N. Pour les associations 1 vers 1, les attributs de l'association peuvent toujours 
etre deplaces dans une des classes qui participent a l'association. Pour les 
associations 1 vers N, le deplacement est generalement possible vers la classe du 
cote N ; toutefois, il est frequent de promouvoir l'association au rang de classe 
pour augmenter la lisibilite ou en raison de la presence d' associations vers 
d'autres classes. L'exemple suivant illustre les differentes situations. 



Diplome 
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Etudiant 
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Travail 
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Figure 153 : Exemples de placement des attributs selon les valeurs de multiplicite. 

L'association entre la classe Etudiant et la classe Travail est de type N 
vers N. La classe Travail decrit le sujet, la solution apportee par l'etudiant 
n'est pas conservee. 

Dans le cas des controles de connaissances, chaque etudiant compose 
individuellement sur un travail donne et la note obtenue ne peut etre stockee ni 
dans un etudiant en particulier (car il effectue de nombreux travaux dans sa 
carriere), ni dans un travail donne (car il y a autant de notes que d'etudiants). La 
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note est un attribut de la relation entre la classe des etudiants et la classe des 
travaux. 

En fin d'annee, chaque etudiant recoit un diplome avec une mention qui depend 
de la performance individuelle de l'etudiant. La relation entre le diplome et 
l'etudiant est personnalisee car un diplome ne concerne qu'un etudiant donne. La 
mention devient un attribut du diplome. La mention n'est pas stockee dans 
l'etudiant pour deux raisons : elle ne qualifie pas un etudiant et un etudiant peut 
obtenir plusieurs diplomes. Chaque etudiant possede une chambre et une 
chambre n'est pas partagee par plusieurs etudiants. L' association entre les 
etudiants et les chambres est du type 1 vers 1. Le numero est un attribut de la 
classe Chambre puisqu'un numero caracterise une chambre. 

Contraintes sur les associations 

Toutes sortes de contraintes peuvent etre definies sur une relation ou sur un 
groupe de relations. La multiplicite presentee dans le paragraphe precedent est 
une contrainte sur le nombre de liens qui peuvent exister entre deux objets. Les 
contraintes se represented dans les diagrammes par des expressions placees 
entre accolades. 

La contrainte {ordonnee} peut etre placee sur le role pour specifier qu'une 
relation d'ordre decrit les objets places dans la collection ; dans ce cas, le modele 
ne specifie pas comment les elements sont ordonnes, mais seulement que l'ordre 
doit etre maintenu durant l'ajout et ou la suppression des objets par exemple. 



Personne 




Compte 




1 0..* 





{Ordonnee} 



Figure 154 : La contrainte {Ordonnee} indique que la collection des comptes d'une 

personne est ordonnee. 

La contrainte {Sous-ensemble} indique qu'une collection est incluse dans 
une autre collection. L'exemple suivant montre que les delegues de parents 
d'eleves sont des parents d'eleves. 



Parents d'eleves 



Classe 




Personne 




{Sous-ensemble}| 







Delegues 



Figure 155 : La contrainte { Sous— ensemble } indique que les objets qui participent a la 
relation Delegues participent egalement a la relation Parents d' Sieves. 
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La contrainte {ou-exclusif} precise que, pour un objet donne, une seule 
association parmi un groupe d' associations est valide. Cette contrainte evite 
l'introduction de sous-classes artificielles pour materialiser l'exclusivite. 



Universite - 



Enseignants 



T 

{Ou-extlusif} 



Etudiants 



Personne 



Figure 156 : Introduction d'une contrainte {Ou-exclusif} pour distinguer deux 
associations mutuellement exclusives. 



Les associations peuvent egalement relier une classe a elle-meme, comme dans le 
cas des structures recursives. Ce type d' association est appele association 
reflexive. Le nommage des roles prend a nouveau toute son importance pour 
distinguer les instances qui participent a la relation. L'exemple suivant montre la 
classe des personnes et la relation qui unie les parents et leurs enfants en vie. 

I P^on^l Parents 

l m 

Enfants | * j 



Figure 157 : Toute personne possede de zero a deux parents, et de zero a plusieurs enfants. Le 
nommage des roles est essentiel a la clarte du diagramme. 



Les classes-associations 

Une association peut etre representee par une classe pour ajouter, par exemple, 
des attributs et des operations dans l'association. Une classe de ce type, appelee 
parfois classe associative ou classe-association, est une classe comme les autres 
et peut a ce titre participer a d' autres relations dans le modele. La notation utilise 
une ligne pointillee pour attacher une classe a une association. Dans l'exemple 
suivant, l'association entre les classes A et B est representee par la classe C, qui 
elle-meme est associee a la classe D. 
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Figure 158 : Exemple de classe-association. 
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Une association qui contient des attributs sans participer a des relations avec 
d'autres classes est appelee association attribuee. Dans ce cas, la classe 
rattachee a 1' association ne porte pas de nom specifique. 



Etudiant 


Realise > 


Travail 




I 





Note 



Figure 159 : Representation d'une association attribuee. 

Restriction des associations 

La restriction (UML parle de qualification) d'une association consiste a 
selectionner un sous-ensemble d'objets parmi l'ensemble des objets qui 
participent a une association. La restriction est realisee au moyen d'un tuple 
d' attributs particuliers (appele cle) et utilise conjointement avec un objet de la 
classe de depart. La cle est representee sur le role de la classe de depart, dans un 
compartiment rectangulaire. La cle appartient pleinement a 1' association et non 
aux classes associees. 



jcjej- 



Figure 160 : Restriction d'une association, au moyen d'un attribut particulier appele cle. 

Chaque instance de la classe A accompagnee de la valeur de la cle, identifie un 
sous-ensemble des instances de B qui participent a 1' association. La restriction 
reduit la multiplicite de l'association. La paire (instance de A, valeur 
de cle) identifie un sous-ensemble des instances de B. Tres souvent, la 
multiplicite est reduite a la valeur 1. 
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Figure 161 : Une restriction reduit le nombre d'instances qui participent a une association. 
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La restriction d'une association peut etre operee en combinant les valeurs des 
differents attributs qui forment la cle. 



Echiquier 








Ligne 




Case 




Colonne 


1 











Figure 162 : Combinaison d'une ligne et d'une colonne pour identifier une case de 

I 'echiquier. 

Les agregations 

Une agregation represente une association non symetrique dans laquelle une des 
extremites joue un role predominant par rapport a l'autre extremite. Quelle que soit 
l'arite l'agregation ne concerne qu'un seul role d'une association. 

L' agregation se represente en ajoutant un petit losange du cote de l'agregat. 

I 1 Une agregation i 1 

_A_0 — B 



Figure 163 : Representation des agregations. 

Les criteres suivants impliquent une agregation : 

• une classe fait partie d'une autre classe ; 

• les valeurs d'attributs d'une classe se propagent dans les valeurs d'attributs 
d'une autre classe ; 

• une action sur une classe implique une action sur une autre classe ; 

• les objets d'une classe sont subordonnes aux objets d'une autre classe. 

L'inverse n'estpas toujours vrai : l'agregation n'implique pas necessairement les 
criteres evoques plus haut. Dans le doute, les associations sont preferables. De 
maniere generale, il faut toujours choisir la solution qui implique le couplage le 
plus faible. 

Les agregations peuvent etre multiples, comme les associations. Tant qu'aucun 
choix de realisation n'a ete effectue, il n'y a aucune contrainte particuliere sur les 
valeurs de multiplicite que peuvent porter les roles d'une agregation. Cela 
signifie, en particulier, que la multiplicite du cote de l'agregat peut etre superieure 
a 1. Ce type d' agregation correspond par exemple au concept de coproprietaire. 
Le diagramme suivant montre que des personnes peuvent etre coproprietaires des 
memes immeubles. 
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Figure 164 : Exemple d'agregat multiple. 

La notion d'agregation ne suppose aucune forme de realisation particuliere. La 
contenance physique est un cas particulier de l'agregation, appele composition. 

La composition 

Les attributs constituent un cas particulier d'agregation realisee par valeur : ils 
sont physiquement contenus par l'agregat. Cette forme d'agregation est appelee 
composition, et se represente dans les diagrammes par un losange de couleur 
noire. 

La composition implique une contrainte sur la valeur de la multiplicite du cote de 
l'agregat : elle ne peut prendre que les valeurs 0 ou 1. La valeur 0 du cote du 
composant correspond a un attribut non renseigne. 



Agregat 


0..1 


Composant 


* 



Figure 165 : Representation graphique de la composition. 

La composition et les attributs sont semantiquement equivalents ; leurs 
representations graphiques sont interchangeables. La notation par composition 
s'emploie dans un diagramme de classes lorsqu'un attribut participe a d'autres 
relations dans le modele. La figure suivante illustre l'equivalence entre la notation 
par attribut et la notation par composition. 
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Moteur 
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Figure 166 : Une agregation par valeur est semantiquement equivalente a un attribut ; elle 
permet de montrer comment un attribut participe d d'autres relations dans le modele. 



Les classes realisees par composition sont egalement appelees classes 
composites. Ces classes fournissent une abstraction de leurs composants. 
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La navigation 

Les associations decrivent le reseau de relations structurelles qui existent entre 
les classes et qui donnent naissance aux liens entre les objets, instances de ces 
classes. Les liens peuvent etre vus comme des canaux de navigation entre les 
objets. Ces canaux permettent de se deplacer dans le modele et de realiser les 
formes de collaboration qui correspondent aux differents scenarios. 

Par defaut, les associations sont navigables dans les deux directions. Dans 
certains cas, seule une direction de navigation est utile ; ceci se represente par 
une fleche portee par le role vers lequel la navigation est possible. L' absence de 
fleche signifie que l'association est navigable dans les deux sens. Dans l'exemple 
suivant, les objets instances de A voient les objets instances de B, mais les objets 
instances de B ne voient pas les objets instances de A 



A 


> 


B 









Figure 167 : L'association entre les classes A et B est uniquement navigable de A vers B. 

Une association navigable uniquement dans un sens peut etre vue comme une 
demi-association. Cette distinction est souvent realisee pendant la conception, 
mais peut tres bien apparaitre en analyse, lorsque l'etude du domaine revele une 
dissymetrie des besoins de communication. 

Expressions de navigation 

UML definit un pseudo-langage pour representer les chemins au sein des 
diagrammes de classes. Ce langage tres simple definit des expressions qui servent 
par exemple a preciser des contraintes. 

La partie gauche de l'expression designe un ensemble d'objets, eventuellement 
reduit a un singleton. Un nom de classe designe 1' ensemble des objets instances 
de la classe. 

La syntaxe des expressions de navigation est donnee par les quatre regies 
suivantes : 

• cible ::= ensemble '.' selecteur 

Le selecteur correspond soit a un nom d'attribut des objets de l'ensemble, soit a 
un nom d' association de la classe des objets, soit a un nom de role oppose sur un 
lien qui concerne les objets de l'ensemble. La cible est un ensemble de valeurs ou 
d'objets, dont le nombre depend de la multiplicite de l'ensemble et de 
l'association. 
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Dans le cas d'une association, l'expression retourne une collection d'objets qui 
contient le nombre d'elements specifies par la multiplicite du role. L'expression 
UnePersonne . En f ants designe toutes les enfants d'une personne donnee. 
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Figure 168 : L'expression UnePersonne . Enfants designe tons les enfants d'une 

personne donnee. 

• cible ::= ensemble '.' '~' selecteur 

Le selecteur correspond a un nom de role place du cote de l'ensemble. La cible est 
un ensemble d'objets, obtenu par navigation dans le sens oppose au nom de role. 

Dans l'exemple precedent, les parents d'une personne sont designes par 
l'expression UnePersonne . ~Enfants. 

• cible ::= ensemble 1 f' expression_booleenne 

L'expression booleenne est construite a partir des objets contenus par l'ensemble 
et a partir des liens et valeurs accessibles par ces objets. La cible est un ensemble 
d'objets qui verifient l'expression. La cible est un sous-ensemble de l'ensemble 
de depart. 

Dans l'exemple precedent, l'expression booleenne UnePersonne . En f ants 
[age>=18ans ] designe tous les enfants majeurs d'une personne donnee. 

• cible : : = 

ensemble '.' selecteur valeur_de_cle 

Le selecteur designe une association qui partitionne l'ensemble a partir de la 
valeur de la cle. La cible est un sous-ensemble de l'ensemble defini par 
1' association. 

Dans l'exemple suivant, une restriction est operee par l'ajout de cles sur 
1' association, ce qui a pour effet de reduire la multiplicite. L'expression generale 
UnePersonne . Enfant [UnPrenom] identifie un enfant donne de maniere 
non ambigue puisque chaque enfant d'une meme famille a un prenom different. 
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Figure 169 : Les valeurs de cles peuvent egalement etre utilisees dans les expressions de 

navigation. 



Les expressions precedentes se preterit particulierement bien a la formalisation 
des pre- et post-conditions attachees aux specifications des operations. Dans 
l'exemple precedent, les operations de creation des liens familiaux doivent 
associer correctement les parents et leurs enfants. Ceci peut s'exprimer sous la 
forme de la contrainte suivante. 



{UnePer sonne = 

UnePersonne . Enfant [UnPrenom ] . (Parent [Mere ] ou 
Parent [Pere ] ) } 



ou encore, en naviguant en sens inverse : 



{UnePersonne = 

UnePersonne . Enfant [UnPrenom ] . (~Enfant [Mere ] ou 
~Enfant [Pere] ) } 



ou enfin, en posant : 

Ij {papa = UnePersonne. Parent [Pere] } 



et 



{papl = UnePersonne. (Parent [Pere] ou 
Parent [Mere ] ) . Parent [Pere ] } 



alors 



{papl . Parent [Pere ] = 
papa . Parent [Pere ] . Parent [Pere ] } 
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ce qui revient a dire, comme chacun sait, que le papa de papi est le papi de papa ! 



La generalisation 

UML emploie le terme generalisation pour designer la relation de classification 
entre un element plus general et un element plus specifique. En fait, le terme 
generalisation designe un point de vue porte sur un arbre de classification. Par 
exemple, un animal est un concept plus general qu'un chat, un chien ou un raton 
laveur. Inversement, un chat est un concept plus specialise qu'un animal. 

L'element plus specifique peut contenir des informations qui lui sont propres, a 
condition de rester totalement coherent avec la description de l'element plus 
general. La generalisation s' applique principalement aux classes, aux paquetages 
et aux cas d'utilisation. 

Dans le cas des classes, la relation de generalisation exprime le fait que les 
elements d'une classe sont aussi decrits par une autre classe (en fait par le type 
d'une autre classe). La relation de generalisation signifie est un ou est une sorte 
de. Un chat est un animal, il s'agit de generalisation. Un chat a deux oreilles, il ne 
s'agit pas de generalisation, mais de composition. 

La relation de generalisation se represente au moyen d'une fleche qui pointe de la 
classe plus specialised vers la classe plus generale. La tete de la fleche est realisee 
par un petit triangle vide, ce qui permet de la distinguer d'une fleche ouverte, 
symbole de la propriete de navigation des associations. Dans l'exemple suivant, 
la classe Animal est une abstraction des classes Chat, Chien et Raton 
laveur. 



Animal 



Chat 




Chien 




Raton laveur 











Figure 170 : Representation de la relation de generalisation entre classes. 



Dans l'exemple precedent, la classe Animal est appelee super-classe et les 
classes Chat, Chien et Raton laveur sont dites sous-classes de la classe 
Animal. 

Dans le cas de sous-classes multiples, les fleches peuvent etre agregees en une 
seule, comme precedemment, ou representees de maniere independante, comme 
suit. Les deux formes de fleches qui symbolisent la generalisation ne vehiculent 
aucune semantique particuliere. 
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Figure 171 : Representation de la generalisation au moyen defleches obliques. 



Les attributs, les operations, les relations et les contraintes definies dans les 
super-classes sont herites integralement dans les sous-classes. En 
programmation, la relation de generalisation est tres souvent realisee en utilisant 
la relation d'heritage entre classes, propose par les langages objet. L'heritage est 
une maniere de realiser la classification, mais ce n'est pas la seule. La relation de 
generalisation definie par UML est plus abstraite que la relation d'heritage telle 
qu'elle existe dans les langages de programmation objet comme C++. L'heritage 
est une relation statique ; elle induit un couplage tres fort entre classes, et se 
revele peu adaptee a la notion de classification dynamique ou a la notion de 
metamorphose. En analyse, il vaut mieux parler de generalisation ou de 
classification, et se preoccuper plus tard, lors de la conception, de la maniere de 
realiser la generalisation. 

Les classes peuvent avoir plusieurs super-classes ; dans ce cas, la generalisation 
est dite multiple et plusieurs fleches partent de la sous-classe vers les differentes 
super-classes. La generalisation multiple consiste a fusionner plusieurs classes 
en une seule classe. Les super-classes n'ont pas necessairement un ancetre 
commun. Dans l'exemple suivant, la classe Tapis volant possede deux 
ancetres completement disjoints, les classes Tapis et Vehicule. La forme de 
generalisation qui regroupe les classes Vehicule, Vehicule 
terrestre 13 , Vehicule Aerien et Tapis volant, est appelee 
generalisation en diamant ou en losange. 



Pour se convaincre que les tapis sont bien des vehicules terrestres, il suffit 
d'observer mes enfants... 



116 - Modelisation objet avec UML 



Tapis 



Vehicule 



Terrestre 




Aerien 







Tapis volant 



Figure 172 : Exemple de generalisation multiple. 

Une classe peut etre specialised selon plusieurs criteres simultanement. Chaque 
critere de la generalisation est indiquee dans le diagramme en associant un 
discriminant a la relation de generalisation. Lorsque les fleches sont agregees, le 
discriminant n'apparait qu'une seule fois. L'absence de discriminant est 
considered comme un cas particulier de generalisation. 



Vehicule 
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Figure 1 73 : Exemple de generalisation selon des criteres independants. 



Differentes contraintes peuvent etre appliquees aux relations de generalisation, 
pour distinguer par exemple les formes de generalisation exclusives des formes 
inclusives. Les contraintes sur les relations de generalisation se represented au 
moyen d'expressions entre parentheses, directement attachees aux 
generalisations agregees ou associees a une ligne pointille qui relie les relations 
de generalisation concernees. 

Par defaut, la generalisation symbolise une decomposition exclusive, c'est-a-dire 
qu'un objet est au plus instance d'une des sous-classes. La contrainte 
{Disjoint} ou {Exclusif} indique qu'une classe descendante d'une 
classe A peut etre descendante d'une seule sous-classe de A. 



3 - La notation UML - 117 




(Exclusif) 



t- 


4 


Pas de k 
melanqe des 
dimensions 










Pied bleu 


Bolet de loup 











Figure 174 : Exemple de classification exclusive. 

La contrainte { Chevauchement } ou {Inclusif} indique qu'une classe 
descendante d'une classe A appartient au produit cartesien des sous-classes de 
la classe A Un objet concret est alors construit a partir d'une classe obtenue par 
melange de plusieurs super-classes. 
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Figure 1 75 : Exemple de classification inclusive. 



La contrainte {Complete} indique que la generalisation est terminee et qu'il 
n'est pas possible de rajouter des sous-classes. Inversement, la contrainte 
{ Incomplete } designe une generalisation extensible. 

j_Cours_j 

j 4 -{tfteomplete) -j^ 

LMathsJ |_Fran5ais[ i Geo J 
Errrd CZZZZZf Ezzzi! 



Figure 176 : La contrainte { Incomplete } signale qu'il peut exister d'autres cours ; la 

classification est extensible. 
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II ne faut pas confondre la contrainte { Incomplete } avec une vue incomplete. 
Une contrainte vehicule un contenu semantique qui affecte le modele. Une vue 
incomplete ne signifie pas que le modele est incomplet. 

De maniere generale, une vue partielle se symbolise par la presence de points 
d'elision qui se substituent aux elements de modelisation dans les differents 
diagrammes. L'exemple suivant montre partiellement la generalisation de la classe 
Cours. 
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Figure 177 : Exemple de vue incomplete. Les points d'elision caracterisent la vue et non le 

modele. 

Les classes abstraites 

Les classes abstraites ne sont pas instanciables directement ; elles ne donnent 
pas naissance a des objets, mais servent de specification plus generale - de type 
- pour manipuler les objets instances d'une (ou plusieurs) de leurs sous-classes. 

Les classes abstraites forment une base pour les logiciels extensibles. L'ensemble 
des mecanismes generaux est decrit dans les termes des specifications des 
classes abstraites, sans tenir compte des specificites rassemblees dans les 
classes concretes. Les nouveaux besoins, les extensions et les ameliorations sont 
concentres dans de nouvelles sous-classes, dont les objets peuvent etre 
manipules de maniere transparente par les mecanismes deja en place. 

Une classe est designee comme abstraite au moyen de la propriete booleenne 
Abstraite definie pour tous les elements generalisables (les types, les 
paquetages et les stereotypes). Par convention, le nom des classes abstraites est 
en italique. 



Classe Abstraite 



Figure 178 : Representation graphique d'une classe abstraite. 

La propriete abstraite peut egalement etre appliquee a une operation afin 
d'indiquer que le corps de l'operation doit etre defini explicitement dans les sous- 
classes. 
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Introduction au metamodele 

De nombreux elements de modelisation presentent une dichotomie commune 
(essence, manifestation) , par laquelle un type represente l'essence 
d'une abstraction et l'instance fournit une manifestation concrete. II existe 
egalement une dichotomie (specification, realisation) par laquelle 
des classes et des types primitifs realisent des types. 

Un type specifie un domaine de valeurs et un ensemble d'operations applicables a 
ces valeurs. Une classe realise un type : elle fournit la representation des attributs 
et la realisation des operations (les methodes). Cette distinction se propage avec 
les sous-classes de sorte que la specification donnee par un type est valable pour 
toutes les sous-classes et qu'une sous-classe peut realiser plusieurs types. 

Le diagramme de classes ci-dessous represente la dichotomie (essence, 
manifestation) et la dichotomie (specification, realisation). 
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Figure 179 : Extrait du metamodele. Une instance manifeste un type, une classe realise un 

type. 



La classe Type comprend les sous-classes suivantes : 

• le type primitif qui correspond a un type qui n'est pas realise par une classe, 
comme les entiers ou les types enumeres, 

• la classe qui fournit la realisation d'un type, 

• le cas d'utilisation qui est une sequence d'actions effectuees par un acteur et 
un systeme. 

Le diagramme suivant represente les differentes sortes de types proposes par 
UML. 
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Figure 180 : Extrait du metamodele. Representation des diffe rentes sortes de types. 

La classe Classe comprend les sous-classes suivantes : 

• la classe active qui reifie un ou plusieurs flots d'execution, 

• le signal qui est un evenement nomme, 

• le composant qui est un element reutilisable contenant les constituants 
physiques des elements de modelisation, 

• le nceud qui est un dispositif physique sur lequel des composants peuvent 
etre deployes pour leur execution. 
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Figure 181 : Extrait du metamodele. Representation des differentes sortes de classes. 

Les relations 

UML definit cinq sortes de relations. La plus generale est appelee relation de 
dependance et s' applique de maniere uniforme a tous les elements de 
modelisation. L' association et la generalisation concernent tous les types, en 
particulier les classes et les cas d'utilisation. Les deux dernieres, les transitions et 
les liens, s'appliquent a certains elements de modelisation du comportement. 

Ce paragraphe se limite a la description des relations statiques entre classes, 
presentees dans le diagramme suivant. Les liens et les transitions sont presentes 
plus loin dans ce chapitre. 
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Figure 182 : Extrait du metamodele. Representation des relations entre classes. 



L' association 

L'association specifie une connexion semantique bidirectionnelle entre types. Une 
association possede au moins deux roles qui decrivent la part prise par les types 
participant a l'association. 
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Figure 183 : Extrait du metamodele. Representation des principals caracteristiques des 

associations. 



Chaque role comprend les attributs suivants : 

• Multiplicite. Specifie le nombre d'instances qui participent a la relation. 

• Navigable. Precise si les liens, instances de l'association, sont navigables 
dans la direction du role considere. 

• Agregat. Specifie si les instances du type associe au role sont le tout dans 
une relation du genre (tout, parties) . Seul un des roles d'une 
association peut posseder un attribut d'agregation positionne a Vrai. Si, de 
plus, la multiplicite de ce role vaut 2, alors le tout possede les parties et la 
destruction du tout entraine la destruction des parties. Si la multiplicite est 
superieure a 1, plusieurs instances jouent le role du tout et partagent les 
parties ; la destruction d'une des instances du tout n'entraine pas la 
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destruction des parties. La destruction de toutes les instances du tout 
entraine la destruction des parties. 

• Changeable. Precise si la semantique de l'association est preservee 
lorsqu'une instance, du type qui participe au role, est remplacee par une autre 
instance. 

• Ordonnee. S'applique lorsque la valeur de la multiplicite est superieure a 2, 
pour signifier que les instances sont ordonnees. 

Un role d'association peut egalement comprendre un tuple d'attributs dont la 
conjonction de valeurs realise une partition de l'ensemble des objets de la classe 
associee. 

La generalisation 

La generalisation specifie une relation de classification par laquelle une instance 
d'un sous-type peut etre substitute a une instance d'un super-type. Un super- 
type peut avoir plusieurs sous-types et un sous-type peut avoir plusieurs super- 
types. 
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Figure 184 : Extrait du metamodele. Representation de la relation de generalisation et des 

elements generalisables. 

Tout element generalisable possede les attributs booleens suivants : 

• Abstrait. La valeur Vrai precise que l'element ne peut etre instancie 
directement. 

• Feuille. La valeur Vrai precise que l'element ne peut avoir des sous-types. 

• Racine. La valeur Vrai precise que l'element ne peut avoir des super-types. 
UML definit trois sortes d'elements generalisables : 
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• Stereotype. Les stereotypes permettent la classification d'un element de 
modelisation et eventuellement la definition d'une representation graphique 
particuliere. Un stereotype ne peut pas avoir de sous-type. 

• Paquetage. Les paquetages offrent un mecanisme general pour le 
regroupement des elements (a la fois de modelisation et de visualisation). Un 
paquetage ne peut pas avoir de super- type. 

• Type. Un type specifie un domaine de definition et les operations applicables 
a ce domaine. 



La dependance 

La dependance est une relation d'utilisation unidirectionnelle entre elements (de 
modelisation et de visualisation). La relation de dependance relie des elements au 
sein d'un meme modele. 



Figure 185 : Extrait du metamodele. Representation des relations de dependance. 

UML definit egalement une relation de trace entre elements qui appartiennent a 
des modeles differents. La trace faciliter peut servir notamment a representer 
l'histoire des constructions presentes dans les differents modeles. Cette relation 
de trace est une relation de dependance stereotypee. 
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Figure 186 : Extrait du metamodele. La relation de trace est une relation de dependance 

stereotypee. 



Les cas d'utilisation 



Les cas d'utilisation (use cases) ont ete formalises par Ivar Jacobson . Les cas 
d'utilisation decrivent sous la forme d'actions et de reactions, le comportement 
d'un systeme du point de vue d'un utilisateur. lis permettent de definir les limites 
du systeme et les relations entre le systeme et l'environnement. 

Les cas d'utilisation viennent combler un manque des premieres methodes objet, 
comme OMT-1 et Booch 91, qui ne proposaient pas de technique pour la 
determination des besoins. En ce sens, les cas d'utilisation associes aux 
techniques objet permettent une approche complete pour 1' ensemble du cycle de 
vie, depuis le cahier des charges jusqu'a la realisation. 

Un cas d'utilisation est une maniere specifique d'utiliser un systeme. C'est 
l'image d'une fonctionnalite du systeme, declenchee en reponse a la stimulation 
d'un acteurexterne. 

Interet des cas d'utilisation 

La determination et la comprehension des besoins sont souvent difficiles car les 
intervenants sont noyes sous de grandes quantites d'information. Les besoins 
sont souvent exprimes de maniere non structuree, sans forte coherence, de sorte 
que les cahiers des charges sont de longues litanies de paragraphes qui 
contiennent des expressions du genre : 



Jacobson I. 1992, Object-Oriented Software Engineering, A Use Case Driven 
Approach, Addison- Wesley. 
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• le systeme devra faire. . . 

• le systeme devrait faire... 

• le systeme fera eventuellement. . . 

• il faut absolument que... 

• il serait interessant de... 

Frequemment, des besoins se contredisent, des oublis sont commis, des 
imprecisions subsistent, et 1' analyse du systeme part sur de mauvaises bases. En 
consequence, le cahier des charges initial est flou et en constante evolution. 
Lorsque les besoins se precisent ou evoluent - ce qui est toujours le cas - il 
devient tres difficile d'apprecier l'impact et le cout d'une modification. 

Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs, en 
partant du point de vue tres simple qui veut qu'un systeme est avant tout 
construit pour ses utilisateurs. La structuration de la demarche s'effectue par 
rapport aux interactions d'une seule categorie d' utilisateurs a la fois ; cette 
partition de l'ensemble des besoins reduit considerablement la complexite de la 
determination des besoins. 



Figure 187 : Les cas d'utilisation partitionnent l'ensemble des besoins d'un systeme. 

Le formalisme des cas d'utilisation - base sur le langage naturel - est accessible 
sans formation particuliere des utilisateurs, qui peuvent ainsi exprimer leurs 
attentes et leurs besoins en communiquant facilement avec les experts du 
domaine et les informaticiens. La terminologie employee dans la redaction des cas 
d'utilisation est celle employee par les utilisateurs dans leur vie de tous les jours, 
de sorte que l'expression des besoins s'en trouve grandement facilitee. Les 
informaticiens, quant a eux, sont constamment ramenes par les cas d'utilisation 
vers les preoccupations premieres des utilisateurs ; ils evitent ainsi de deriver 
vers des constructions techniquement seduisantes, mais pas forcement 
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necessaries aux utilisateurs. Les cas d'utilisation focalisent l'effort de 
developpement sur les vrais besoins. 

Les cas d'utilisation permettent aux utilisateurs de structurer et d'articuler leurs 
desks ; ils les obligent a definir la maniere dont ils voudraient interagir avec le 
systeme, a preciser quelles informations ils entendent echanger et a decrire ce qui 
doit etre fait pour obtenir le resultat escompte. Les cas d'utilisation concretisent 
le futur systeme dans une formalisation proche de l'utilisateur ; ils favorisent la 
definition d'un cahier des charges qui reflete reellement les besoins, meme en 
l'absence d'un systeme a critiquer. 

Le modele des cas d'utilisation 

Le modele des cas d'utilisation comprend les acteurs, le systeme et les cas 
d'utilisation eux-memes. L'ensemble des fonctionnalites d'un systeme est 
determine en examinant les besoins fonctionnels de chaque acteur, exprimes sous 
forme de families d' interactions dans les cas d'utilisation. Les acteurs se 
representent sous la forme de petits personnages qui declenchent des cas 
d'utilisation ; ces derniers sont represented par des ellipses contenues par le 
systeme. 



Un acteur represente un role joue par une personne ou une chose qui interagit 
avec un systeme. Les acteurs se determinent en observant les utilisateurs directs 
du systeme, ceux qui sont responsables de son exploitation ou de sa 
maintenance, ainsi que les autres systemes qui interagissent avec le systeme en 
question. La meme personne physique peut jouer le role de plusieurs acteurs 
(vendeur, client). D' autre part, plusieurs personnes peuvent jouer le meme role, et 
done agir comme le meme acteur (tous les clients). Le nom de 1' acteur decrit le role 
joue pari' acteur. 

Dans l'exemple suivant, Monsieur Schmoldu, garagiste de son etat, passe le plus 
clair de son temps dans le role du mecanicien, mais peut a 1' occasion jouer le role 
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Figure 188 : Representation des acteurs au moyen de petits personnages. 
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de vendeur. Le dimanche, il joue le role de client et entretient sa voiture 
personnelle. 




Vendre 



Figure 189 : Une meme personne physique peut jouer le role de plusieurs acteurs. 

Les candidats acteurs se recrutent parmi les utilisateurs, les clients, les 
partenaires, les fournisseurs, les vendeurs, les autres systemes, en resume, les 
personnes et les choses exterieures a un systeme qui interagissent avec lui en 
echangeant de l'information (en entree et en sortie). La determination des acteurs 
permet de preciser les limites du systeme de maniere progressive : floues au 
depart, elles se precisent au fur et a mesure de l'elaboration des differents cas 
d'utilisation. Cette activite de delimitation est extremement importante car elle sert 
de base contractuelle ou est signale ce qui doit etre fait, ce qui fait partie du 
systeme a developper et ce qui n'en fait pas partie. Elle precise egalement les 
elements intangibles, que l'equipe de developpement ne peut pas modifier. 

II existe quatre grandes categories d' acteurs : 

• Les acteurs principaux. Cette categorie regroupe les personnes qui utilisent 
les fonctions principales du systeme. Dans le cas d'un distributeur de billets, 
il s'agit des clients. 

• Les acteurs secondaires. Cette categorie regroupe les personnes qui 
effectuent des taches administratives ou de maintenance. Dans le cas d'un 
distributeur de billets, il s'agit de la personne qui recharge la caisse contenue 
dans le distributeur. 

• Le materiel externe. Cette categorie regroupe les dispositifs materiels 
incontournables qui font partie du domaine de 1' application et qui doivent etre 
utilises. II ne s'agit done pas de l'ordinateur sur lequel s'execute l'application, 
mais des autres dispositifs materiels peripheriques. Dans le cas d'un 
distributeur de billets, ce peut etre l'imprimante. 
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• Les autres systemes. Cette categorie regroupe les systemes avec lesquels le 
systeme doit interagir. Dans le cas d'un distributeur de billet, le systeme du 
groupement bancaire qui gere un pare de distributeurs apparait comme un 
acteur. 

Une fois identifies, les acteurs doivent etre decrits d'une maniere claire et concise, 
en trois ou quatre lignes maximum. Lorsqu'il y a beaucoup d'acteurs dans un 
systeme, il est conseille de les regrouper par categories afin de faciliter la 
navigation dans le modele des cas d' utilisation. 

Les cas d'utilisation se determinent en observant et en precisant, acteur par 
acteur, les sequences d'interaction - les scenarios - du point de vue de 
l'utilisateur. lis se decrivent en termes d' informations echangees et d'etapes dans 
la maniere d'utiliser le systeme. Un cas d'utilisation regroupe une famille de 
scenarios d'utilisation selon un critere fonctionnel. Les cas d'utilisation sont des 
abstractions du dialogue entre les acteurs et le systeme : ils decrivent des 
interactions potentielles, sans entrer dans les details de chaque scenario. 

Les cas d'utilisation doivent etre vus comme des classes dont les instances sont 
les scenarios. Chaque fois qu'un acteur interagit avec le systeme, le cas 
d'utilisation instancie un scenario ; ce scenario correspond au flot de messages 
echanges par les objets durant l'interaction particuliere qui correspond au 
scenario. L'analyse des besoins par les cas d'utilisation s'accommode tres bien 
d'une approche iterative et incremental. 

La portee des cas d'utilisation depasse largement la definition des seuls besoins 
du systeme. En effet, les cas d'utilisation interviennent tout au long du cycle de 
vie, depuis le cahier des charges jusqu'aux tests, en passant par l'analyse, la 
conception, la realisation et la redaction de la documentation pour l'utilisateur. De 
ce point de vue, il est possible de naviguer vers les classes et les objets qui 
collaborent pour satisfaire un besoin, puis vers les tests qui verifient que le 
systeme s'acquitte correctement de sa tache. 
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Figure 190 : Les cas d'utilisation servent defil conducteur pour V ensemble du pro jet. 

Les relations entre cas d'utilisation 

Les diagrammes de cas d'utilisation representent les cas d'utilisation, les acteurs 
et les relations entre les cas d'utilisation et les acteurs. UML definit trois type de 
relations entre acteurs et cas d'utilisation : 

• La relation de communication. La participation de l'acteur est signalee par 
une fleche entre l'acteur et le cas d'utilisation. Le sens de la fleche indique 
l'initiateur de 1' interaction. 




Acteur 

Figure 191 : Representation du declenchement d'un cas d'utilisation par un acteur. 

• La relation d'utilisation. Une relation d'utilisation entre cas d'utilisation 
signifie qu'une instance du cas d'utilisation source comprend egalement le 
comportement decrit par le cas d'utilisation destination. 
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«Utilise» 

Cas d'utilisation B 
Cas d'utilisation A 

Figure 192 : Representation de la relation d' utilisation au moyen d'une relation de 
generalisation stereotypee. 

• La relation d 'extension. Une relation d'extension entre cas d'utilisation 
signifie que le cas d'utilisation source etend le comportement du cas 
d'utilisation destination. 

«Etend» 

o 

Cas d'utilisation B 

Cas d'utilisation A 

Figure 193 : Representation de la relation d'extension au moyen d'une relation de 
generalisation stereotypee. 

Le diagramme suivant donne un exemple de mise en oeuvre des differentes 
relations entre cas d'utilisation. Le virement par Minitel est une extension du 
virement effectue en agence. Dans les deux cas, le client doit etre identifie. 




Client local 



Identification 

Figure 194 : Exemple de mise en ceuvre des differentes relations entre cas d' utilisation. 



Construction des cas d'utilisation 

Un cas d'utilisation possede une valeur ajoutee qui procure a l'utilisateur un 
resultat appreciable. Un cas d'utilisation doit avant tout etre simple, intelligible, 
decrit de maniere claire et concise. Le nombre d'acteurs qui interagissent avec le 
cas d'utilisation est tres limite : en regie generate, il n'y a qu'un seul acteur par 
cas d'utilisation. 
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Lors de la construction des cas d'utilisation, il faut se demander : 

• quelles sont les taches de 1' acteur ? 

• quelles informations 1' acteur doit-il creer, sauvegarder, modifier, detruire ou 
simplement lire ? 

• 1' acteur devra-t-il informer le systeme des changements externes ? 

• le systeme devra-t-il informer 1' acteur des conditions internes ? 

Les cas d'utilisation peuvent etre presentes aux travers de vues multiples : un 
acteur avec tous ses cas d'utilisation, un cas d'utilisation avec tous ses acteurs, 
etc. 

Les cas d'utilisation peuvent egalement etre groupes selon leurs sequences de 
declenchement types, c'est-a-dire en fonction de leurs enchainements, ou encore 
en fonction des differents points de vue, souvent correles aux grandes categories 
d'acteurs (client, fournisseur, maintenance...). 

L'etape suivante consiste a classer les cas d'utilisation selon leur acuite par 
rapport a l'activite de la societe, leur interet pour les clients, la nature des risques, 
la simplicite de leur mise en ceuvre ou leur impact sur les processus deja en place. 

Regies de mise en ceuvre des cas d'utilisation 

Un cas d'utilisation decrit non seulement une fonctionnalite ou une motivation, 
mais aussi une interaction entre un acteur et un systeme sous la forme d'un flot 
d'evenements. La description de l'interaction se concentre sur ce qui doit etre fait 
dans le cas d'utilisation, pas sur la maniere de le faire. 

Un cas d'utilisation doit rester simple. II ne faut pas hesiter a fragmenter un cas 
d'utilisation si les interactions deviennent trop complexes, trop enchevetrees, ou 
encore si des parties se revelent etre independantes. II faut egalement veiller a ne 
pas melanger les cas d'utilisation ; les acteurs et les interactions d'un autre cas 
d'utilisation ne doivent pas etre mentionnes dans la description. Enfin, les cas 
d'utilisation doivent eviter d'employer des expressions floues et imprecises, 
construites a partir de mots comme beaucoup, plutot, suffisamment, assez, etc. 

La description d'un cas d'utilisation comprend les elements suivants : 

• le debut du cas d' utilisation, autrement dit l'evenement qui declenche le cas 
d'utilisation ; il doit etre clairement stipule dans la phrase suivante : « Le cas 
d'utilisation debute quand Xse produit. » ; 

• la fin du cas d'utilisation, autrement dit l'evenement qui cause l'arret du cas 
d'utilisation ; il doit etre clairement identifie et documente par la phrase: 
« Quand Yse produit, le cas d'utilisation est termine. » ; 

• l'interaction entre le cas d'utilisation et les acteurs qui decrit clairement ce 
qui est dans le systeme et ce qui est hors du systeme ; 
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• les echanges d' informations qui correspondent aux parametres des 
interactions entre le systeme et les acteurs. Une formulation non informatique 
est recommandee, par exemple : « L'utilisateur se connecte au systeme et 
donne son nom et son mot de passe. » ; 

• La chronologie et I'origine des informations qui decrivent quand le systeme 
a besoin d' informations internes ou externes et quand il les enregistre a 
l'interieur ou a l'exterieur ; 

• Les repetitions de comportement qui peuvent etre decrites au moyen de 
pseudo-code, avec des constructions du type : 

boucle 

— quelque chose 
fin de boucle 

ou 

pendant que 

— autre chose 
fin pendant 

• Les situations optionnelles qui doivent etre representees de maniere uniforme 
dans tous les cas d' utilisation ; les differentes options doivent apparaitre 
clairement selon la formulation : 

« L'acteur choisit l'un des elements suivants, eventuellement plusieurs fois de 
suite : 

a) choix X 

b) choix y 

c) choix Z 

puis l'acteur continue en... » 

Ces points ne suffisent pas pour obtenir un bon cas d' utilisation. II est egalement 
primordial de trouver le bon niveau d' abstraction, c'est-a-dire la quantite de 
details qui doivent apparaitre, et de faire la distinction entre un cas d' utilisation et 
un scenario. II n'y a malheureusement pas de reponse toute faite, de sorte que 
1' appreciation du niveau d'abstraction repose grandement sur l'experience. Les 
reponses apportees aux deux interrogations suivantes peuvent neanmoins servir 
de gabarit : 
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• est-il possible d'executer une activite donnee independamment des autres, ou 
faut-il toujours l'enchainer avec une autre activite ? Deux activites qui 
s'enchainent toujours font probablement partie du meme cas d'utilisation ; 

• est-il judicieux de regrouper certaines activites en vue de les documenter, de 
les tester ou de les modifier ? Si oui, ces activites font surement partie du 
meme cas d'utilisation. 

Lorsqu'un cas d'utilisation devient trop complexe (plus de dix pages par exemple), 
il est possible de le decouper en cas d'utilisation plus petits. Cette operation n'est 
toutefois effectuee que lorsque les cas d'utilisation ont ete decrits en detail, apres 
examen des principaux scenarios. 

Processus a" elaboration des cas d'utilisation 

Les cas d'utilisation permettent le travail en groupe, a condition de definir un 
guide de style pour la redaction. Ce guide contient une description de la mise en 
page des cas d'utilisation, du niveau de details, ainsi qu'un modele de cas 
d'utilisation qui sera repris par tous les intervenants. 

L'equipe commence par identifier grossierement les cas d'utilisation. Les 
principales etapes de chaque cas d'utilisation sont decrites en une phrase ou 
deux, en distinguant le cas nominal des cas alternatifs et exceptionnels. Une fois 
ce premier travail realise, des groupes issus de l'equipe se chargent d'approfondir 
la comprehension et la description d'un cas d'utilisation particulier. Pour ce faire, 
chaque groupe identifie les scenarios et les conditions de differenciation entre 
scenarios a partir de la connaissance du domaine et de rencontres avec les 
utilisateurs. 

Un scenario est un chemin particulier au travers de la description abstraite et 
general e fournie par le cas d'utilisation. Les scenarios traversent le cas 
d'utilisation, en suivant le chemin nominal ainsi que tout chemin alternatif et 
exceptionnel. L'explosion combinatoire fait qu'il est bien souvent impossible de 
derouler tous les scenarios. 
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Figure 195 : Un cas d' utilisation decrit (de maniere abstraite) une famille de scenarios. 

Lorsque le contenu du cas d' utilisation a ete valide par le deroulement des 
scenarios, les etapes stabilisees doivent etre decrites de maniere plus detaillee. A 
chaque etape correspond alors un paragraphe qui decrit ce qui se passe dans 
l'etape, en tenant compte a priori de tous les scenarios qui traversent l'etape. A 
ce stade, tous les besoins identifies dans les scenarios doivent etre pris en 
compte par un cas d'utilisation. 

II est fortement conseille de synchroniser revolution des cas d'utilisation par des 
reunions regulieres entre groupes de l'equipe. Ceci presente le double avantage 
d'harmoniser le niveau de detail des cas d'utilisation et de permettre la 
reallocation des scenarios orphelins, en mal de cas d'utilisation. 

Ces reunions permettent egalement de faire valider les cas d'utilisation d'un 
groupe par les autres groupes. Des criteres simples, issus de l'experience, aident a 
distinguer un bon cas d'utilisation d'un moins bon. II faut par exemple se poser 
les questions suivantes : 

• existe-t-il une breve description qui donne une vraie image du cas 
d'utilisation ? 

• les conditions de demarrage et d'arret du cas d'utilisation sont-elles bien 
cernees ? 

• les utilisateurs sont-ils satisfaits par la sequence d' interactions entre l'acteur 
et le cas d'utilisation ? 

• existe-t-il des etapes communes avec d'autres cas d'utilisation ? 

• les memes termes employes dans des cas d'utilisation differents ont-ils bien la 
meme signification ? 

• est-ce que toutes les alternatives sont prises en compte par le cas 
d'utilisation ? 
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Les derniers pieges a eviter 

Les cas d'utilisation ne sont pas la seule maniere de documenter les besoins d'un 
systeme. Les techniques traditionnelles, a base de descriptions textuelles 
informelles, peuvent tres bien accompagner les cas d'utilisation. II est alors 
judicieux d'etablir des references croisees entre les deux types de documentation 
et d'etudier les points suivants : 

• est-ce que tous les besoins identifies de maniere informelle ont ete alloues a 
un cas d'utilisation ? 

• est-ce qu'un meme besoin a ete alloue a plusieurs cas d'utilisation ? 

• existe-t-il des cas d'utilisation qui ne sont pas references par des besoins 
informels ? 

D' autre part, le maquettage a base de constructeurs d'interface utilisateur est tres 
souvent le meilleur moyen d'aider l'utilisateur final a articuler ses desirs. L'examen 
des interactions entre l'utilisateur et la maquette procure alors une source non 
negligeable de scenarios, et done de moyens de valider le modele des cas 
d'utilisation. 

La principale difficulte d'emploi liee aux cas d'utilisation reside plus dans la 
determination du niveau de detail, que dans la formulation des cas d'utilisation. II 
faut se rappeler que les cas d'utilisation sont une abstraction d'un ensemble de 
comportements fonctionnellement lies au sein d'un cas d'utilisation. La presence 
d'un grand nombre de details par exemple, est le signe d'un scenario plus que 
d'un cas d'utilisation. 

Dans le meme ordre d'idee, un grand nombre de cas d'utilisation est le signe d'un 
manque d' abstraction. Dans n'importe quel systeme, quelle que soit sa complexite 
et sa taille, il y a relativement peu de cas d'utilisation, mais beaucoup de 
scenarios. Typiquement, un systeme moyen comprend de dix a vingt cas 
d'utilisation ; un grand nombre de cas d'utilisation signifie que l'essence du 
systeme n'a pas ete comprise. Un cas d'utilisation decrit ce que l'utilisateur veut 
fondamentalement faire avec le systeme. Le nom des cas d'utilisation peut etre un 
indicateur, les associations (objet, operations) ou (fonction, donnees) sont 
fortement suspectes. 

Une autre difficulte consiste a resister a la tentation de trop decrire le 
comportement interne du systeme, au detriment de l'interaction entre l'acteur et le 
systeme. II est vrai que le cas d'utilisation doit decrire ce que l'utilisateur echange 
avec le systeme et les grandes etapes dans 1' elaboration de ces echanges ; mais 
cela ne va pas jusqu'a expliquer comment le systeme realise ces echanges. Le cas 
d'utilisation est un outil d'analyse utilise pour determiner ce que l'utilisateur 
attend du systeme, e'est-a-dire le quoi et le quoi faire du systeme. Des lors que la 
description fait appel au comment, il ne s'agit plus d'analyse mais de conception. 
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La transition vers les objets 

Les cas d'utilisation recentrent le developpement sur les besoins de l'utilisateur; 
ils aident done a construire le bon systeme (Build the right system comme diraient 
nos amis anglo-saxons). Les cas d'utilisation ne definissent pas pour autant la 
bonne maniere de faire le systeme (Build the system right comme diraient toujours 
nos amis) ni la forme de l'architecture du logiciel ; ils disent ce qu'un systeme doit 
faire, pas comment il doit le faire. 

La vue des cas d'utilisation est une description fonctionnelle des besoins, 
structuree par rapport a un acteur. Le passage a l'approche objet s'effectue en 
associant une collaboration a chaque cas d'utilisation. Une collaboration decrit 
des objets du domaine, les connexions entre ces objets et les messages echanges 
par les objets. Chaque scenario, instance du cas d'utilisation realise par la 
collaboration, se represente par une interaction entre les objets decrits dans le 
contexte de la collaboration. 



Cas d'utilisation 



Collaboration 



<<Realise>> 



= <Participe' 



" — 3" 



\ 



^Participe- 



/ «Parlicipe >> \ 



Objst 




i 

Objet 




Objet 



Figure 196 : La transition vers I'objet est effectuee en realisant un cas d'utilisation par une 

collaboration. 



La realisation d'un cas d'utilisation par une collaboration est un instant crucial de 
la modelisation ; e'est le moment du virage vers I'objet. Une decomposition qui 
suit directement la forme des cas d'utilisation conduit a une approche structuree 
classique, avec tous les defauts des structures calquees sur les fonctions. 

Une approche objet realise un cas d'utilisation au moyen d'une collaboration 
entre objets. Les scenarios, instances du cas d'utilisation, sont representes par 
des diagrammes d' interaction (diagrammes de collaboration et diagrammes de 
sequence). 

La figure suivante illustre le choix de decomposition apres 1' etude des cas 
d'utilisation. 
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Figure 197 : Representation du virage vers I'objet apres une etude des cas d 'utilisation. 



Les diagrammes d'objets 



Les diagrammes d'objets, ou diagrammes d'instances, montrent des objets et des 
liens. Comme les diagrammes de classes, les diagrammes d'objets represented la 
structure statique. La notation retenue pour les diagrammes d'objets est derivee 
de celle des diagrammes de classes ; les elements qui sont des instances sont 
soulignes. 

Les diagrammes d'objets s'utilisent principalement pour montrer un contexte, par 
exemple avant ou apres une interaction, mais egalement pour faciliter la 
comprehension des structures de donnees complexes, comme les structures 
recursives. 



138 - Modelisation objet avec UML 



Representation des objets 

Chaque objet est represente par un rectangle qui contient soit le nom de 1' objet, 
soit le nom et la classe de l'objet (separes par un double point), soit seulement la 
classe de l'objet (l'objet est alors dit anonyme). Le nom seul correspond a une 
modelisation incomplete dans laquelle la classe de l'objet n'a pas encore ete 
precisee. La classe seule evite l'introduction de noms inutiles dans les 
diagrammes, tout en permettant l'expression de mecanismes generaux, valables 
pour de nombreux objets. Le diagramme suivant illustre les trois possibilites de 
representation. 



Nom de l'objet 



Nom de l'objet : Classe 



: Classe 



Figure 198 : Representations graphiques d'un objet ; le nom ou la classe de l'objet peuvent 
etre supprim.es du diagramme. 



Le nom de la classe peut contenir le chemin complet, compose a partir des noms 
des differents paquetages englobants separes par des doubles deux points, 
comme dans l'exemple suivant : 



BoutonOK : IHM::Contr6les::BoutonPoussoir 



Figure 199 : Exemple de representation du chemin d'acces complet de la classe de l'objet. 



Le stereotype de la classe peut etre repris dans le compartiment de l'objet, soit 
sous la forme textuelle (entre guillemets au dessus du nom de l'objet), soit sous la 
forme graphique (dans le coin haut droit), soit encore au moyen d'une 
representation graphique particuliere qui se substitue au symbole de l'objet. II 
n'existe pas de stereotype d'objet ; le stereotype qui figure dans un objet est 
toujours le stereotype de la classe de l'objet. 



«ExceDtion» 
DivisionParZero 



Figure 200 : Exemple de representation du stereotype de la classe dans le symbole d'un 

objet. 



Les rectangles qui symbolisent les objets peuvent egalement comporter un 
deuxieme compartiment qui contient les valeurs des attributs. Le type des 
attributs est deja decrit dans la classe, de sorte qu'il n'est plus necessaire de le 
faire figurer dans les representations d'objets. Le diagramme suivant represente 
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un objet anonyme de la classe Voiture, muni d'un attribut Couleur dont la 
valeur est rouge. 

■ Voiture 
Couleur = rouge 



Figure 201 : Exemple d' objet anonyme de la classe Voiture, muni d'un attribut 
Couleur dont la valeur est rouge. 



Representation des liens 

Les objets sont relies par des liens qui sont instances des relations entre les 
classes des objets considered. La representation concrete d'une structure par des 
objets est souvent plus parlante que celle abstraite par des classes, surtout dans 
le cas de structures recursives. 

Le diagramme d'objets suivant montre une partie de la structure generale des 
voitures. Chaque voiture possede un moteur et quatre roues (roue de secours 
exclue !). 



: Voiture 



: Moteur 



: Roue 




: Roue 




: Roue 




: Roue 



Figure 202 : Exemple de diagramme d'objets. 

Le diagramme d'objets precedent est instance du diagramme de classes suivant. 



Voiture 




Moteur 




1 1 





Roue 



Figure 203 : Exemple de diagramme de classes. Representation generale de la situation 
particuliere montree dans la figure precedente. 

Les liens instances des associations reflexives peuvent relier un objet a lui-meme. 
Dans ce cas, le lien est represente par une boucle attachee a un seul objet. Le 
diagramme suivant represente deux liens, instances de la meme association 
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reflexive. Le premier lien montre qu'Etienne est le patron de Jean-Luc, le deuxieme 
lien montre que Denis est son propre patron. 



Collaborateur 



Personne 



Patron 



Etienne 


Personne 


/ 


/ Patron 


Jean-Luc : Personne 





f \ 


Patron 


Denis 


Personne 



Figure 204 : Exemple de liens instances d'une relation reflexive. Etienne est le patron de 
Jean-Luc, Denis est son propre patron. 

La plupart des liens sont binaires. II existe toutefois certains liens d'arite 
superieure, par exemple ceux qui correspondent aux relations ternaires. La 
representation des liens ternaires peut se combiner avec les autres elements de la 
notation : le diagramme suivant represente une famille de liens ternaires, instances 
d'une association ternaire de multiplicite Wdu cote de la classe Etudiant. Cette 
notation presente l'avantage de lever les ambigui'tes inherentes a la 
representation de la multiplicite des associations d'arite superieure a 2. 



Prof 



: Salle 



<> 



: Etudiant 



Figure 205 : Exemple de combinaison d 'elements de notation pour representer de maniere 
condensee des liens ternaires multiples. 



Les objets composites 

Les objets composes de sous-objets peuvent etre represented au moyen d'un 
objet composite, afin de reduire la complexite des diagrammes. Les objets 
composites se presentent comme des objets classiques, si ce n'est que les 
attributs sont remplaces par des objets, soit sous une forme textuelle soulignee, 
soit sous une forme graphique. Le diagramme suivant reprend la forme graphique 
des objets composites. 



Un composite 


















: Partie 




: Partie 




: Partie 



















Figure 206 : Representation graphique des objets composites. 
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Les objets composites sont instances de classes composites, c'est-a-dire de 
classes construites a partir d'autres classes par la plus forte forme d'agregation. 
Le diagramme suivant represente une classe composite Fenetre. 



Fenetre 




2 


Ascenseu 




1 



"1 



1 

Zone de dessin 



Figure 207 : Exemple d'une classe composite Fenetre qui contient une zone de dessin et 

deux ascenseurs. 

Le diagramme d'objets suivant est instance du diagramme de classe precedent : 0 
represente la forme generale des objets composites Fenetre, du point de vue 
des objets. 



: Fenetre 



: Zone de dessin 



: Ascenseur 



: Ascenseur 



Figure 208 : Representation d'un objet composite, instance de la classe composite decrite 
dans le diagramme precedent. 



Similitudes avec les diagrammes de classes 

Les decorations qui figurent dans les diagrammes de classes peuvent en grande 
partie etre reportees dans les diagrammes d'objets, afin de faciliter la 
comprehension de l'interaction. Ceci concerne toutes les caracteristiques des 
associations (le nom, le nom des roles, l'agregation, la composition et la 
navigation), a 1' exception de la multiplicite qui se represente de maniere explicite 
par les liens. Le diagramme d'objets suivant se distingue graphiquement d'un 
diagramme de classe car les noms d'objets sont soulignes. 
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Passagers ■ Pprsnnns 




: Bus 




Conducteur 



: Personne 



: Destination 



Figure 209 : Exemple de diagramme d'objets, decore comme un diagramme de classes. 

Les valeurs des cles de restriction des associations peuvent egalement etre 
rajoutees dans les diagrammes d'objets. Le diagramme suivant represente les 
liens de parente entre Lara, Jonathan, Roxane, Anne et Pierre- Alain. 



Figure 210 : Exemple de representation des valeurs des cles de restriction des associations. 



Les diagrammes de collaboration montrent des interactions entre objets, en 
insistant plus particulierement sur la structure spatiale statique qui permet la mise 
en collaboration d'un groupe d'objets. Les diagrammes de collaboration 
expriment a la fois le contexte d'un groupe d'objets (au travers des objets et des 
liens) et l'interaction entre ces objets (par la representation des envois de 
messages). Les diagrammes de collaboration sont une extension des diagrammes 
d'objets. 

Representation des interactions 

Le contexte d'une interaction comprend les arguments, les variables locales 
creees pendant l'execution, ainsi que les liens entre les objets qui participent a 
l'interaction. 



Jonathan 




Les diagrammes de collaboration 
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Une interaction est realisee par un groupe d'objets qui collaborent en echangeant 
des messages. Ces messages sont represented le long des liens qui relient les 
objets, au moyen de fleches orientees vers le destinataire du message. 

Le diagramme suivant represente une cabine d'ascenseur qui demande a une 
porte de s' ouvrir. 




Figure 211 : Exemple d' interaction entre deux objets. La cabine demande a la porte de 

s 'ouvrir. 



Dans un diagramme de collaboration, le temps n'est pas represente de maniere 
implicite, comme dans un diagramme de sequence, de sorte que les differents 
messages sont numerates pour indiquer l'ordre des envois. 




Porte 



: Lumiere 



Figure 212 : Exemple de representation de l'ordre des envois de message. 

Les diagrammes de collaboration montrent simultanement les interactions entre 
les objets et les relations structurelles qui permettent ces interactions. Le 
diagramme suivant represente le contexte d'un mecanisme pour annuler une 
operation de destruction. Avant de declencher 1' operation de destruction de 
l'objet B, l'objet A effectue une copie locale de B, de sorte que si l'operation de 
destruction venait a etre annulee, l'objet B puisse etre restitue tel qu'il etait avant 
le deroulement de 1' interaction. 



144 - Modelisation objet avec UML 



Destruction 



A 










B 



.{local} 



Copie de B 



Figure 213 : Representation d'une interaction entre trois objets. L'objet B a ete copie 
localement par l'objet A, dans le but de permettre I'annulation eventuelle de la destruction de 

B. 

Les objets et les liens crees ou detruits au cours d'une interaction peuvent 
respectivement porter les contraintes {nouveau} ou {detruit}. Les objets 
crees, puis detruits au sein de la meme interaction, sont identifies par la contrainte 
{ transitoire}. 




Figure 214 : Representation de la creation et de la destruction des objets et des liens. 



La notation permet de representer de maniere condensee une famille de liens, 
instances d'une meme association. Cette approche est particulierement 
interessante lorsque le groupe d'objets considere est traite de maniere uniforme, 
en etant par exemple destination d'un meme message. L'exemple suivant montre 
un instituteur qui demande a tous ses eleves de se lever ; l'iteration est indiquee 
par le caractere * place devant le message. 



Instituteur 




Eleve 




1 






*[tous] : Debout 



Figure 215 : Representation condensee d'une famille de liens, instances d'une meme 

association. 
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La place de I'utilisateur 

La notation permet de faire figurer un acteur dans un diagramme de collaboration 
afin de representer le declenchement des interactions par un element externe au 
systeme. Grace a cet artifice, l'interaction peut etre decrite de maniere plus 
abstraite, sans entrer dans les details des objets de l'interface utilisateur. Le 
premier message de l'interaction est envoye par l'acteur, represente soit par le 
symbole graphique des acteurs du modele des cas d' utilisation, soit par un objet 
muni d'un stereotype qui precise sa qualite d' acteur. Le diagramme suivant 
montre un fragment d' interaction ; elle correspond a un appel de cabine 
d'ascenseur par une personne. 



Les objets actifs 

Les objets qui possedent le flot de controle sont dits d' actifs. Un objet actif peut 
activer un objet passif pour le temps d'une operation, en lui envoyant un 
message. Une fois le message traite, le flot de controle est restitue a l'objet actif. 
Dans un environnement multitache, plusieurs objets peuvent etre actifs 
simultanement. Un objet actif se represente par un rectangle dont la bordure est 
plus epaisse que celle des objets passifs. 




2: Ajouter destination RDC 



Figure 216 : Exemple de declenchement d'une interaction par un acteur. 



: Traitement de texte[ 




Figure 217 : Representation des objets actifs. Le cadre des objets actifs est plus epais que 

celui des objets passifs. 
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Representation des messages 

Un message se represente par une fleche placee a proximite d'un lien et dirigee 
vers l'objet destinataire du message. Un lien sert de support de transmission pour 
le message. Un message declenche une action dans l'objet destinataire. 

Les messages respectent la forme generale suivante : 

synchronisation sequence ' : ' resultat ':=' nom 
arguments 

Le message, ses arguments et valeurs de retour, son rang au sein de l'interaction, 
et diverses autres informations comme le degre d'emboitement ou la 
synchronisation sont precises lors de 1' envoi. 

Synchronisation 

Le point de synchronisation d'un message est exprime sous la forme d'une 
sequence d'envoi de message, terminee par le caractere /. Tous les messages 
references dans cette liste doivent avoir ete envoyes pour valider l'envoi du 
message courant. 

La syntaxe d'un point de synchronisation prend la forme suivante : 

synchronisation ::= rang { \ ' synchronisation} '/' 

rang ::= [entier / nom de flot d' execution] { \ ' rang} 

L'entier represente le rang de l'envoi de message au sein de l'emboitement 
englobant. Le nom identifie un flot d'execution parallele au sein d'un 
emboitement. Ainsi, l'envoi de message 3.1.3 suit immediatement l'envoi 
3.1.2 au sein de l'emboitement 3.1, alors que l'envoi 3.1. a est effectue 
simultanement a l'envoi 3. l.b. 

Dans l'exemple suivant, le message Message est envoye lorsque les envois A . 1 
et B . 3 ont ete satisfaits. 



A.1, B.3 / Message 




A 



Figure 218 : Exemple de representation de la synchronisation entre flots d' execution 

paralleles. 

Sequence 

La sequence indique le niveau d'emboitement de l'envoi de message au sein de 
l'interaction. La sequence est constituee d'une suite de termes separes par des 
points. Chaque sequence possede la syntaxe suivante : 
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sequence ::= rang [recurrence] 

La recurrence represente l'iteration et les branchements conditionnels ; elle prend 
les formes suivantes : 

recurrence ::= clause d' iteration bloc 

ou 

recurrence ::= clause de condition bloc 

La clause d' iteration est optionnelle ; elle est exprimee dans un format libre : 

A 

=1..n] : Message 
:X -i 



Figure 219 : Exemple de representation de l'iteration. 

La notation de l'iteration sous-entend l'envoi sequentiel des messages contenus 
par le bloc. L'envoi parallele (egalement appele diffusion) est materialise par la 
suite de caracteres */ / . 

La clause de condition valide ou non l'envoi des messages contenus par le bloc. 
La clause de condition est exprimee dans un format libre : 



B 




Figure 220 : Exemple de representation d'un envoi de message conditionnel. 

Resultat 

Le resultat est constitue d'une liste de valeurs retournees par le message. Ces 
valeurs peuvent etre utilisees comme parametres des autres messages compris 
dans l'interaction. Ce champ n'existe pas en l'absence de valeurs retournees. Le 
format de ce champ est libre : 
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B 




Figure 221 : Representation de la recuperation d'un resultat. 

Nom 

II s'agit du nom du message. Souvent ce nom correspond a une operation definie 
dans la classe de 1' objet destinataire du message. 

Arguments 

II s'agit de la liste des parametres du message. Les arguments et le nom du 
message identifient de maniere unique Taction qui doit etre declenchee dans 
1' objet destinataire. Les arguments peuvent contenir des valeurs retournees par 
des messages envoyes precedemment, ainsi que des expressions de navigation 
construites a partir de l'objet source. 

Les expressions suivantes donnent quelques exemples de la syntaxe d' envoi des 
messages : 

4 : Afficher (x, y) — message simple 

3.3.1 : Afficher (x, y) — message imbrique 

4.2 : age := Soustraire (Aujourd' hui, 
DateDeNaissance) 

— message imbrique avec valeur retournee 

[Age >= 18 ans] 6.2 : Voter () — message 
condi t i onnel 

4. a, b.6 / c.l : Allumer (Lampe) — 
synchronisation avec d' autres flots d' execution 

1 * : Laver () — iteration 

3. a, 3.b / 4 *\\[i := l..n] : Eteindre () — 
iteration parallele 
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Les arguments des messages sont represented dans les diagrammes, soit en 
utilisant du pseudo-code, soit directement dans la syntaxe du langage de 
programmation. La notation propose egalement une representation graphique des 
arguments sous la forme de fleches terminees par de petits cercles. Le diagramme 
suivant donne un exemple de representation graphique des arguments d'un 
message. 





Message 






Argument o — > 

< — 0 Argument 




A 


B 





Figure 222 : Representation graphique des arguments d'un message au moyen de fleches 
terminees par de petits cercles. 

Introduction au metamodele 
Les collaborations 

Une collaboration est un mecanisme compose d'elements structurels et 
comportementaux. Les collaborations fournissent un mecanisme d'organisation, 
mais possedent, contrairement aux paquetages, une identite et une portee 
semantique. Un meme element peut intervenir dans plusieurs collaborations. 

Une collaboration englobe deux genres de construction : un contexte compose 
d'une description de la structure statique des objets concerned et une interaction 
representee par une sequence de messages echanges par les dits objets. Les deux 
aspects sont requis pour pleinement documenter le comportement, mais chaque 
aspect peut etre visualise independamment. 

Les collaborations s'emploient, selon leur niveau de detail, pour decrire des 
specifications et pour exprimer des realisations. Le tableau suivant resume les 
elements de modelisation qui peuvent etre decrits par une collaboration. 



Specification 


Type 


Operation 


Cas d'utilisation 


Realisation 


Classe 


Methode 


Realisation de cas d'utilisation 



Figure 223 : Tableau recapitulatif des elements de modelisation qui peuvent etre decrits par 

des collaborations. 



Les collaborations existent egalement sous une forme generique (modele), 
parametree par des classes, des relations, des attributs et des operations. Une 
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collaboration generique est appelee pattern, ou scheme 15 et micro-architecture en 
francais. Les patterns possedent toujours un nom, contrairement aux 
collaborations qui peuvent rester anonymes. 



Element de modelisation 

5~~ 



Type 



0..1 

Represente 



Operation 



-fOut- 



0..1 

Represente 



Comportement 



0..1 



Collaboration 



Modele : Booleen 



Type 



Relation 



Contrainte 



Note 



Instance 



Figure 224 : Extrait du metamodele. Representation des collaborations. 

Les interactions 

Une interaction exprime le comportement qui resulte de la collaboration d'un 
groupe d'instances. Une interaction peut etre visualisee selon le point de vue du 
temps (par les diagrammes de sequence) ou selon le point de vue de l'espace (par 
les diagrammes de collaboration). Les interactions comprennent principalement 
les elements suivants : 

• les instances qui sont la manifestation concrete d'un type, 

• les liens qui relient les instances et servent de support pour les envois de 
message, 

• les messages qui declenchent les operations, 

• les roles joues par les extremites des liens. 



15 Ma preference va a cette traduction, mais a l'heure actuelle tout le monde parle 
de pattern, j' en ferai done autant ! 
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Relation 











0..* 








1 ien 


0..* 


Association 






0..1 



Message 


♦ 


Role 


0..* 1 



Figure 225 : Extrait du metamodele. Representation des interactions. 



Les diagrammes de sequence 



Les diagrammes de sequence montrent des interactions entre objets selon un 
point de vue temporel. Le contexte des objets n'est pas represente de maniere 
explicite comme dans les diagrammes de collaboration. La representation se 
concentre sur l'expression des interactions. 

Representation des interactions 

Un diagramme de sequence represente une interaction entre objets en insistant 
sur la chronologie des envois de messages. La notation est derivee des Object 
Message Sequence Chart 16 du Siemens Pattern Group. Un objet est materialise 
par un rectangle et une barre verticale appelee ligne de vie des objets. 



Nom : Classe 



I 
I 
| 

Figure 226 : Representation graphique d'un objet. 

Les objets communiquent en echangeant des messages representes au moyen de 
fleches horizontales, orientees de l'emetteur du message vers le destinataire. 
L'ordre d'envoi des messages est donne par la position sur l'axe vertical. L'axe 



Wiley 1996, Pattern-Oriented Software Architecture : A System of Patterns. 
ISBN 0471958697. 
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vertical peut etre gradue afin d'exprimer precisement les contraintes temporelles, 
dans le cas par exemple de la modelisation d'un systeme temps reel. 



Un obiet 



Un autre obiet 



Encore un obiet 



Un message 


Un autre message^ 







Figure 227 : Exemple de diagramme de sequence. 

En modelisation objet, les diagrammes de sequence s'utilisent de deux manieres 
bien differentes, selon la phase du cycle de vie et le niveau de detail desire. 

La premiere utilisation correspond a la documentation des cas d'utilisation ; elle 
se concentre sur la description de l'interaction, souvent dans des termes proches 
de l'utilisateur et sans entrer dans les details de la synchronisation. L'indication 
portee sur les fleches correspond alors a des evenements qui surviennent dans le 
domaine de 1' application. A ce stade de la modelisation, les fleches ne 
correspondent pas encore a des envois de messages au sens des langages de 
programmation, et la distinction entre flots de controle et flots de donnees n'est 
generalement pas operee. La figure suivante represente le debut d'une 
communication telephonique. 



Appelant 




Ligne 




Appele 






teleohoniaue 







Decroche 



Tonalite 



Numerotatiorj^j 
Indicatiorji de sonnerie ! Sonnerie 



f* 

N * 


» 

Decroche 


<s 

16 







Figure 228 : Exemple d'utilisation d'un diagramme de sequence pour la representation 
d' evenements qui surviennent dans le domaine. 
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La deuxieme utilisation correspond a un usage plus informatique et permet la 
representation precise des interactions entre objets. Le concept de message unifie 
toutes les formes de communication entre objets, en particulier l'appel de 
procedure, l'evenement discret, le signal entre flots d' execution ou encore 
l'interruption materielle. 

Les diagrammes de sequence distinguent deux grandes categories d'envois de 
message : 

• les envois synchrones pour lesquels l'emetteur est bloque et attend que 
l'appele ait fini de traiter le message, 

• les envois asynchrones pour lesquels l'emetteur n'est pas bloque et peut 
continuer son execution. 

Un envoi synchrone se represente par une fleche qui part de l'emetteur du 
message et pointe vers son destinataire. Un envoi asynchrone se represente par 
une demi-fleche. 



Messaae svnchrone 



Message asynchrone 



Figure 229 : Representation graphique des envois de message synchrones et asynchrones. 



La fleche qui symbolise un message peut etre representee en oblique pour 
materialiser les delais de transmission non negligeables par rapport a la 
dynamique generale de 1' application. 



Un objet i j Un autre objet | 
I ! ! ! 

Un message 



Figure 230 : Representation d'un delai de propagation. 



Un objet peut egalement s'envoyer un message. Cette situation se represente par 
une fleche qui boucle sur la ligne de vie de l'objet. 
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Un obiet 



Message 
reflexif 



Figure 231 : Exemple d' envoi de message reflexif. 



Cette construction ne correspond pas toujours a un vrai message ; elle peut 
indiquer un point d'entree dans une activite de plus bas niveau, qui s'exerce au 
sein de l'objet. Les interactions internes (entre objets contenus par un objet 
composite) representees par un message reflexif peuvent aussi etre decrites dans 
un diagramme de sequence. 





ComDosant b 


ComDosant aj 





Point d'entree 




Figure 232 : Utilisation d'un message reflexif comme point d'entree d'une interaction 

interne. 



La creation des objets se represente en faisant pointer le message de creation sur 
le rectangle qui symbolise l'objet cree. La destruction est indiquee par la fin de la 
ligne de vie et par une lettre X, soit a la hauteur du message qui cause la 
destruction, soit apres le dernier message envoye par un objet qui se suicide. 
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I" Un obiet 1 
I I 



Creer 




) 


Un autre ohiet 


Detruire 


1 
1 
1 



Figure 233 : Representation de la creation et de la destruction des objets. 

Les diagrammes de sequence permettent egalement de representer les periodes 
d'activite des objets. Une periode d'activite correspond au temps pendant lequel 
un objet effectue une action, soit directement, soit par 1' intermediate d'un autre 
objet qui lui sert de sous-traitant. Les periodes d'activite se represented par des 
bandes rectangulaires placees sur les lignes de vies. Le debut et la fin d'une 
bande correspondent respectivement au debut et a la fin d'une periode d'activite. 

j" Un obiet 1 
I I 

Activation j 
->n 

U 
I 
! 

Figure 234 : Representation de la periode d'activite d'un objet au moyen d'une bande 
rectangulaire superposee a la ligne de vie de Vobjet. 

Le diagramme suivant montre le cas d'un objet A qui active un autre objet B. La 
periode d'activite de l'objet A recouvre la periode d'activite de l'objet B. Dans le 
cas d'un appel de procedure, le flot d'execution est passe par l'objet A a l'objet B. 
L'objet A est alors bloque jusqu'a ce que l'objet B lui redonne la main. 
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*0 



Figure 235 : Exemple d' objet qui active un autre objet. 



Dans le cas d'un appel de procedure, et plus generalement dans le cas des envois 
synchrones, le retour en fin d'execution de l'operation est implicite : il n'est pas 
necessaire de le representer dans les diagrammes. L'objet A reprend son 
execution lorsque Taction declenchee dans l'objet Best terminee. 



A 



E 



Retour 
imolicite 



Figure 236 : Dans le cas des envois synchrones, le retour est implicite en fin d'activite et ne 
necessite pas de representation particuliere. 



En revanche, dans le cas des envois asynchrones, le retour doit etre materialise 
lorsqu'il existe. Le diagramme suivant montre un objet B initialement active par un 
objet A, qui retourne un message a l'objet A avant de cesser son execution. II faut 
noter que la fin de l'activation d'un objet ne correspond pas a la fin de sa vie. Un 
meme objet peut etre active de nombreuses fois au cours de son existence. 
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Retour ; 

explicite I 
I 
I 



Retour 
explicite 
avant suicide 



Figure 237 : Representation explicite du retour dans le cas des envois asynchrones. La lettre 
X symbolise une fin d'activite qui correspond egalement a une fin de vie. 

Le cas particulier des envois de messages recursifs se represente par un 
dedoublement de la bande rectangulaire. L'objet apparait alors comme s'il etait 
actif plusieurs fois. 



] Un obiet j 
I I 



Recursion 



Figure 238 : Representation de la recursion dans les diagrammes de sequence. 



Structures de contrdle 

Les formes des diagrammes de sequence refletent indirectement les choix de 
structure. Les deux diagrammes suivants presentent respectivement un mode de 
controle centralise et un mode decentralise. 
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1 B 










1 ~ 


1 ~ 



Con role centralise 



A 




B 


1 - 


1 - 


J. 









~*0 



Contnle dece itralise 



Figure 239 : La forme des diagrammes de sequence est le reflet du mode de controle de 

V interaction. 



Les diagrammes de sequence peuvent etre completes par des indications 
textuelles, exprimees sous la forme de texte libre ou de pseudo-code. L'instant 
d'emission d'un message, appele transition, peut etre nomme dans le diagramme a 
proximite du point de depart de la fleche qui symbolise le message. Ce nom sert 
alors de reference, par exemple pour construire des contraintes temporelles, 
comme dans le diagramme suivant. Lorsque la propagation d'un message prend 
un temps significatif par rapport a la dynamique du systeme, les instants 
d'emission et de reception des messages sont materialises par un couple (nom, 
nom prime) . 



B 



(y-x < 3 s} 
{z-y < 1 s} 



ft'-t < 2 s) 



-Message 



-Message 3-r 

Q^-Message 



Message i 



Figure 240 : Exemples de contraintes temporelles construites a partir de noms de transitions. 

L'ajout de pseudo-code sur la partie gauche du diagramme permet la 
representation des boucles et des branchements, de sorte que les diagrammes de 
sequence peuvent representer la forme generale d'une interaction, au-dela de la 
seule prise en compte d'un scenario particulier. 
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Le diagramme suivant represente une boucle While. L'objet A envoie sans 
discontinuer un message a B tant que la condition Xest vraie. 



while X 
loop 



end loop 



n Message ! 



"0 



Figure 241 : Exemple de representation d'une boucle While au moyen de pseudo-code. 

La boucle while peut egalement etre representee au moyen d'une condition 
d'iteration placee directement sur le message. L'iteration est alors symbolisee par 
le caractere * place devant la condition entre crochets. 



*[X] Message 



Figure 242 : Representation alternative de la boucle While au moyen d'une condition 
placee devant le message. 

Comme pour les boucles, les branchements conditionnels peuvent etre 
materialises au moyen de pseudo-code place sur la gauche du diagramme. Le 
diagramme suivant montre que l'objet A envoie un message a l'objet B ou a 
l'objet C selon la condition X. 
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If X 

else 
end if 



Message 

^0 



Message 



Figure 243 : Representation des branchements conditionnels par I'ajout de pseudo-code. 

Comme precedemment, des conditions placees devant les messages peuvent se 
substituer au pseudo-code. Les differentes branches sont alors materialisees par 
plusieurs fleches qui prennent leur origine au meme instant et se distinguent par 
les conditions placees devant les messages. A chaque branchement, les 
conditions doivent etre mutuellement exclusives, et tous les cas doivent etre 
couverts. 



A 



E 



[X] Message 



[non X] Message 
T I 

I i 
I i 
I I 



^0 

I 



Figure 244 : Representation graphique des branchements conditionnels. 



Les alternatives, du cote du destinataire du message, sont representees en 
dedoublant la ligne de vie de l'objet destinataire. La distinction entre les branches 
est indiquee par une condition placee cette fois-ci derriere le message, a proximite 
du point d'entree sur la ligne de vie de l'objet destinataire. 
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■) Message — 1~» 
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Figure 245 : Representation graphique des branchements conditionnels. 



Le pseudo-code permet egalement de mettre en correspondance l'interaction 
initiale, decrite par l'utilisateur lors de F etude des cas d' utilisation, avec une 
interaction entre objets du domaine, construite par l'analyste. 



Les diagrammes d'etats-transitions 



Les diagrammes d'etats-transitions visualisent des automates d'etats finis, du 
point de vue des etats et des transitions. 

Les automates 

Le comportement des objets d'une classe peut etre decrit de maniere formelle en 
termes d'etats et d'evenements, au moyen d'un automate relie a la classe 
consideree. 



I Classe lo 1 Automate 

! J 1 0..1I ! 

Figure 246 : Un automate peut etre associe a chaque classe du modele. 

Les objets qui ne presentent pas un comportement reactif tres marque peuvent 
etre considered comme des objets qui restent toujours dans le meme etat : leurs 
classes ne possedent alors pas d' automate. 

Le formalisme retenu par UML pour representer les automates s'inspire des 
Statecharts" . II s'agit d'automates hierarchiques, possedant les concepts 
d'orthogonalite, d'agregation et de generalisation (ces notions sont definies plus 
loin dans le chapitre). 



Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science 
of Computer Programming vol. 8. 
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Un automate est une abstraction des comportements possibles, a V image des 
diagrammes de classes qui sont des abstractions de la structure statique. Chaque 
objet suit globalement le comportement decrit dans 1' automate associe a sa classe 
et se trouve a un moment donne dans un etat qui caracterise ses conditions 
dynamiques. 

Les automates et les scenarios sont complementaires. Les scenarios se 
representent par une collaboration entre objets. La forme de l'interaction entre les 
objets qui collaborent au sein d'un scenario est determinee par les etats respectifs 
des differents objets. Les automates peuvent etre utilises pour decrire le 
comportement de groupes d'objets, en associant un automate a un composite, 
voire a un cas d'utilisation. 

Un feu tricolore passe successivement de l'etat vert, a l'etat orange puis a l'etat 
rouge, avant de repasser a l'etat vert, et ainsi de suite durant toute sa periode de 
fonctionnement. 



Feu tricolore 



Rouge 



Orange 



Vert 



^1 I 

Figure 247 : De maniere generate, tous lesfeux tricolores sont soit a l'etat rouge, soit a l'etat 

orange, soit a l'etat vert. 

II est bien evident qu'il faut synchroniser l'etat des feux qui se trouvent places 
autour du meme carrefour. Cette synchronisation, qui depend de l'etat du 
carrefour, peut aussi etre decrite dans un automate associe a la classe des 
carrefours. 

Les etats 

Chaque objet est a un moment donne dans un etat particulier. Les etats se 
representent sous la forme de rectangles arrondis ; un chaque etat possede un 
nom qui l'identifie. 
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Un etat 



Un autre etat 



Figure 248 : Les etats se representent au moyen de rectangles arrondis. Chaque etat possede 
un nom qui doit etre unique dans une portee lexicale donnee. 

Les etats se caracterisent par la notion de duree et de stabilite. Un objet est 
toujours dans un etat donne pour un certain temps et un objet ne peut etre dans 
un etat inconnu ou non defini. Un etat est toujours l'image de la conjonction 
instantanee des valeurs contenues par les attributs de 1' objet, et de la presence 
ou non de liens, de l'objet considere vers d'autres objets. 

Le diagramme de classes suivant represente des personnes qui travaillent pour 
des societes. 



Societe 




Personne 




0..1 1..* 


Age 









Figure 249 : Les personnes travaillent pour des societes. 

Les personnes ne possedent pas toutes un emploi et se trouvent, a un moment 
donne, dans un des etats suivants : en activite, au chomage ou a la retraite. La 
figure suivante visualise les trois etats d'une personne. 



En activite 



A la retaite 



Au chomage 



Figure 250 : Une personne peut etre soit en activite, soit au chomage, soit a la retraite. 

Pour connaitre la situation d'une personne en particulier, il faut etudier la 
conjonction suivante : 

• age de la personne, 

• presence d'un lien vers une societe. 

Dans le diagramme suivant, il n'y a pas de lien entre Toto, age de 30 ans, et une 
societe : Toto est done au chomage. Titi, quant a lui, possede un lien vers une 
societe et est age de 40 ans : Titi est done en activite. Ernest, enfin, ne possede 
pas de lien vers une societe et est age de 75 ans : Ernest est done a la retraite. 
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Toto 

Age : 30 an< 



: Societe 




Titi 




Age : 40 an; 



Ernest 

Age : 75 an: 



Figure 251 : L'etat des trois personnes est different. Toto est au chomage, Titi en activite et 

Ernest d la retraite. 

Les automates retenus par UML sont deterministes. Un diagramme d'etats- 
transitions ne doit pas laisser de place aux constructions ambigues. Cela signifie 
en particulier qu'il faut toujours decrire l'etat initial du systeme. Pour un niveau 
hierarchique donne, il y a toujours un et un seul etat initial. En revanche, il est 
possible d' avoir plusieurs etats finaux qui correspondent chacun a une condition 
de fin differente. II est egalement possible de n' avoir aucun etat final, dans le cas 
par exemple d'un systeme qui ne s'arrete jamais. 

L'etat initial se represente par un gros point noir. Un etat final se represente par 
un gros point noir encercle. 

A Etat intermediaire 



Etat initial Etat final 

Figure 252 : L'etat initial est represente par un point noir. Un etat final est represente par un 

point noir encercle. 

Les transitions 

Lorsque les conditions dynamiques evoluent, les objets changent d'etat en 
suivant les regies decrites dans 1' automate associe a leurs classes. Les 
diagrammes d'etats-transitions sont des graphes diriges. Les etats sont relies par 
des connexions unidirectionnelles, appelees transitions. Le passage d'un etat a 
l'autre s'effectue lorsqu'une transition est declenchee par un evenement qui 
survient dans le domaine du probleme. Le passage d'un etat a un autre est 
instantane car le systeme doit toujours etre dans un etat connu. 
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Figure 253 : Une transition permet de passer d'un etat a un autre etat ; elle se represente au 
moyen d'une fleche qui pointe de I'etat de depart vers I'etat d'arrivee. 

Les transitions ne relient pas necessairement des etats distincts. L'exemple 
suivant decrit un fragment d'analyseur lexical. La reconnaissance des unites 
lexicales est effectuee dans un etat de lecture. L'automate reste dans cet etat tant 
que les caracteres lus ne sont pas des separateurs. 

Pas un separateur 




Lecture unite lexicale 



Sepe rateur 
B 



Figure 254 : Exemple de transition d'un etat vers lui-meme dans un fragment d'automate 

lexical. 



Les evenements 

Un evenement correspond a l'occurrence d'une situation donnee dans le domaine 
du probleme. Contrairement aux etats qui durent, un evenement est par nature une 
information instantanee qui doit etre traitee sans plus attendre. Un evenement 
sert de declencheur pour passer d'un etat a un autre. Les transitions indiquent les 
chemins dans le graphe des etats. Les evenements determinent quels chemins 
doivent etre suivis. Les evenements, les transitions et les etats sont 
indissociables dans la description du comportement dynamique. Un objet, place 
dans un etat donne, attend l'occurrence d'un evenement pour passer dans un 
autre etat. De ce point de vue, les objets se component comme des elements 
passifs, controles par les evenements en provenance du systeme. 



A 


Evenement 




f — 


B 









Figure 255 : Un evenement declenche la transition qui lui est associee. 

La syntaxe generale d'un evenement suit la forme suivante : 
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Nom_De_L_Evenement (Nom_De_Parametre : Type, . . . ) 

La specification complete d'un evenement comprend : 

• le nom de 1' evenement, 

• la liste des parametres, 

• 1' objet expediteur, 

• 1' objet destinataire, 

• la description de la signification de l'evenement. 

Dans l'exemple suivant, chaque transition porte l'evenement qui la declenche. 

Plus de 60 ans 



En activite 



Perte d'err ploi 



Embauche 



A la retraite 



Au chomage 



Plus de 60 ans 



Figure 256 : Exemple d 'automate. 

La communication par evenement est de type asynchrone, atomique, et 
unidirectionnelle. Un objet peut envoyer un evenement a un autre objet qui doit 
toujours etre a meme de l'interpreter. 



Un evenement 



Un obiet 




Un autre obiet 





Figure 257 : Un objet peut envoyer un evenement asynchrone a un autre objet. 

Les besoins de communication par evenements synchrones ou les echanges 
bidirectionnels peuvent se representer au moyen de deux echanges asynchrones 
de direction opposee. 





Une question 




Un obiet 




Un autre obiet 






Figure 258 : Les besoins de communication par evenements synchrones peuvent se realiser 
au moyen de deux evenements asynchrones, de direction opposee. 
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Dans ce cas, il appartient a l'objet emetteur de la requete de se mettre en attente 
de la reponse. Ceci implique que l'automate d'etats finis qui le decrit possede une 
sequence du type suivant : 



A 



, r Question posee 

* ' 

Attente reponse 





r Reponse recue 




B 





Figure 259 : Extrait de l'automate d'un objet qui communique de maniere synchrone a 
partir d'evenements asynchrones. L' emetteur de la requete doit se mettre en attente de la 

reponse. 



Les gardes 

Une garde est une condition booleenne qui valide ou non le declenchement d'une 
transition lors de l'occurrence d'un evenement. 





A 


Evenement[ Condition \^ 




B 


* 






. 





Figure 260 : Representation des gardes. 



Les gardes permettent de maintenir l'aspect deterministe d'un automate d'etats 
finis, meme lorsque plusieurs transitions peuvent etre declenchees par le meme 
evenement. Lorsque l'evenement a lieu, les gardes - qui doivent etre 
mutuellement exclusives - sont evaluees et une transition est validee puis 
declenchee. Dans l'exemple suivant, lorsqu'il fait trop chaud, les gardes 
permettent selon la saison de declencher un climatiseur ou d'ouvrir tout 
simplement les fenetres. 



II fait trop chaud[ ete ] 



II fait trop chaud[ hiver 



Climatiser 



Aerer 



Figure 261 : L'evenement il fait trop chaud entraine la climatisation ou I'ouverture 

des fenetres selon la saison. 



168 - Modelisation objet avec UML 



Les operations, les actions et les activites 

Le lien entre les operations definies dans la specification de classe et les 
evenements apparaissant dans les diagrammes d'etats-transitions est effectue par 
l'intermediaire des actions et des activites. 

Chaque transition peut etre decoree par le nom d'une action a executer lorsque la 
transaction est declenchee par un evenement. Pour respecter la semantique 
generale de la transition, Taction est consideree comme instantanee et atomique. 



A 


Evenement / Action 




B 






- — 





Figure 262 : Lorsqu'une transition est declenchee, V action qui lui est attachee est executee 

instantanement. 

L'action correspond a une des operations declarees dans la classe de l'objet 
destinataire de l'evenement. L'action a acces aux parametres de l'evenement, ainsi 
qu'aux attributs de l'objet. En realite, toute operation prend un certain temps a 
s'executer ; la notion d'action instantanee doit s'interpreter comme une operation 
dont le temps d' execution est negligeable devant la dynamique du systeme. 

Les etats peuvent egalement contenir des actions ; elles sont executees a l'entree 
ou a la sortie de l'etat ou lors de l'occurrence d'un evenement pendant que l'objet 
est dans l'etat. 



Etat A 

entry: 
on UnEvenement: 
exit 



Figure 263 : Une action peut etre executee a l'entree ou a la sortie d'un etat, ou en cas 
d 'evenement survenant dans l'etat. 

L'action d' entree (symbolisee par le mot-cle entry:) est executee de maniere 
instantanee et atomique des l'entree dans l'etat. De meme, Taction de sortie 
(symbolisee par exit :) est executee a la sortie de l'etat. L'action sur evenement 
interne (symbolisee par on: ) est executee lors de l'occurrence d'un evenement 
qui ne conduit pas a un autre etat. Un evenement interne n'entraine pas 
Texecution des actions d'entree et de sortie, contrairement au declenchement 
d'une transition reflexive. 
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on E1 : Action 
entry: Action d'entree 
exit: Action de sortie 



E1 / Action 



A. 



entry: Action d'entree 
exit: Action de sortie 



Figure 264 : Un evenement interne n'entraine pas V execution des actions de sortie et 
d'entree, contrairement au declenchement d'une transition reflexive. 

Les actions correspondent a des operations dont le temps d' execution est 
negligeable. Une operation qui prend du temps correspond a un etat plutot qu'a 
une action. Le mot-cle do; indique une activite, c'est-a-dire une operation qui 
prend un temps non negligeable et qui est executee pendant que l'objet est dans 
un etat donne. 



Etat A 

do: Une operation 



Figure 265 : Les operations qui durent sont forcement executees au sein d'un etat. Elles sont 
identifiees par le mot-cle do : suivi du nom de V operation. 

Contrairement aux actions, les activites peuvent etre interrompues a tout moment, 
des qu'une transition de sortie de l'etat est declenchee. Certaines activites sont 
cycliques et ne s'arretent que lorsqu'une transition de sortie est declenchee. 
D'autres activites sont sequentielles et demarrent a l'entree dans l'etat (tout de 
suite apres l'execution des actions d'entree). 

Lorsqu'une activite sequentielle parvient a son terme, l'etat peut etre quitte si une 
des transitions est franchissable. Ce type de transition qui n'est pas declenchee 
par un evenement est appelee transition automatique. 
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do: Activite sequentiell 
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do: Activite sequentielle 



' not X I 



Figure 266 : Lorsque V activite se termine, les transitions automatiques - sans evenements, 
mais eventuellement protegees par des gardes - sont declenchees. 

Les etats peuvent egalement contenir des variables exprimees sous la forme 
d'attributs. Les variables d'etat appartiennent a la classe associee a 1'automate, 
mais peuvent etre representees dans les diagrammes d'etats-transitions 
lorsqu'elles sont manipulees par les actions ou les activites. 



Login 



Norn 

Mot de passe 



Figure 267 : Exemple de representation de variables d'etat. 

Points d'execution des operations 

En resume, il existe six points pour specifier les operations qui doivent etre 
executees. Ces points sont, dans l'ordre d'execution : 

Taction associee a la transition d'entree (Opl), 

Taction d'entree de Tetat (0p2), 

T activite dans Tetat (Qp3), 

Taction de sortie de Tetat (Op4), 

Taction associee aux evenements internes (0p5), 

Taction associee a la transition de sortie de Tetat (Op6). 



3 - La notation UML - 171 



/Op1 
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Un etat 

entry: Op2 
do: Op3 
exit: Op4 
on UnEvenement: Op5 



/Op6 




Figure 268 : Le formalisme des diagrammes d'etats-transitions offre six points pour specifier 
les operations qui doivent etre executees. 



Generalisation d'etats 

Les diagrammes d'etats-transitions peuvent devenir assez difficiles a lire lorsque, 
du fait de l'explosion combinatoire, le nombre de connexions entre etats devient 
eleve : le diagramme se met alors a ressembler a un plat de spaghettis. 

La solution pour maitriser cette situation consiste a utiliser le principe de 
generalisation d'etats. Les etats plus generaux sont appeles super-etats, les etats 
plus specifiques sont appeles sous-etats. Cette approche d' abstraction procede 
de la meme demarche que la generalisation et la specialisation des classes ; elle 
facilite la representation et permet d'occulter les details. 

Un etat peut etre decompose en plusieurs sous-etats disjoints ; les sous-etats 
heritent des caracteristiques de leur super-etat, en particulier des variables d'etat 
et des transitions externes. La decomposition en sous-etats est egalement appelee 
decomposition disjonctive (decomposition de type ou-exclusif) car l'objet doit 
etre dans un seul et un seul sous-etat a la fois. 

Les deux diagrammes suivants illustrent la simplification apportee par la 
generalisation d'etats. 
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Figure 269 : Exemple d'automate dans lequel la transition E2 peut etre factorisee. 
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Figure 270 : Representation hierarchique de V automate precedent. 

Les transitions internes peuvent etre heritees, sauf si la decomposition en sous- 
etats a pour objet de definir un etat particulier pour le traitement d'une transition 
interne. Les transitions d' entree ne sont pas heritees par tous les etats ; seul un 
etat (le super-etat ou un de ses sous-etats) peut etre cible de la transition. Dans 
l'exemple suivant, l'etat B est divise en deux sous-etats Bl et B2. La transition 
d'entree dans l'etat B doit etre reportee sur un des sous-etats, soit directement 
(comme dans le diagramme suivant), soit indirectement au moyen d'un etat initial 
emboite. 



A 

V J 




B 


> 









B 






A 






B1 








-> 


< 












/ 

t 










/ 1 


B2 































Figure 271 : L'etat B est divise en deux sous-etats Bl et B2. La transition d'entree dans l'etat 
B doit etre reportee directement sur un des sous etats. 

Dans l'exemple precedent, l'etat A est relie au sous-etat Bl. Cette situation 
manque d' abstraction et est comparable a un mecanisme ecrit selon la 
specification d'une super-classe, mais ayant besoin de connaitre le detail des 
sous-classes. II est toujours preferable de limiter les liens entre niveaux 
hierarchiques d'un automate en definissant systematiquement un etat initial pour 
chaque niveau. Le diagramme suivant limite les connaissances entre niveaux. 
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Figure 272 : Amelioration du niveau d' abstraction d'un automate par I'ajout d'un etat 

initial dans un super-etat. 

La visualisation exhaustive des sous-etats induit une forte charge d'information 
dans les diagrammes. Le detail des sous-etats peut etre masque, pour donner par 
exemple une vision de plus haut niveau. Grace a la notion de souche il est 
possible de montrer que les transitions entrantes dans un etat composite 
concernent un sous-etat particulier, sans pour autant entrer dans les details de la 
representation de ces sous-etats. 




Figure 273 : Les souches reduisent la charge d'information, tout en materialisant la presence 

des sous-etats de B. 



Agregation d'etats 

L'agregation d'etats est la composition d'un etat a partir de plusieurs autres etats 
independants. La composition est de type conjonctive (composition de type et) 
ce qui implique que l'objet doit etre simultanement dans tous les etats composant 
l'agregation d'etats. La conjonction d'etats represente une forme de parallelisme 
entre automates. 

L'exemple suivant illustre differents aspects de la notion d'agregation d'etats. 
L'etat S est un agregat forme de deux etats independants T et U ; T est compose 
des sous-etats X, Y et Z, et U des sous-etats A et B. Le domaine de S est le 
produit cartesien de T et U. 
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Figure 274 : Exemple d' automate a agregation d'etats. L'etat S appartient au produit 
cartesien des etats T et U. 

Une transition entrante dans l'etat S implique l'activation simultanee des 
automates ret U, c'est-a-dire que l'objet est place dans l'etat composite (Z,A) . 
Lorsque l'evenement E3 a lieu, les automates T et U peuvent evoluer 
independamment, ce qui amene l'objet de l'etat composite (Z,A) vers l'etat 
composite (X, A) . Les automates T et U peuvent evoluer simultanement, ce qui 
est le cas lorsque l'evenement El emmene l'objet de l'etat composite (X, A) vers 
l'etat composite (Y,B). 

L'ajout de conditions sur les transitions, comme la garde [in Z] placee sur la 
transition de B vers A, permet d'introduire des relations de dependance entre 
composants de l'agregat. Lorsque l'evenement E4 a lieu, la transition de B vers A 
est validee uniquement si l'objet est a ce moment-la egalement dans l'etat Z. 

L'agregation d'etats, tout comme la generalisation d'etats, permet de simplifier la 
representation des automates. La generalisation simplifie par factorisation, 
l'agregation simplifie par segmentation de l'espace des etats. Sans agregation 
d'etats, l'automate equivalent serait de la forme suivante : 
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Figure 275 : Automate a plat equivalent a I' automate a agregation precedent. 



Le nombre d'etats d'un tel automate a plat est au maximum egal au produit du 
nombre d'etats de chaque automate composant. Dans le cas d'une agregation de 
trois automates d'une centaine d'etats chacun (ce qui est deja beaucoup), 
l'automate a plat equivalent pourrait contenir jusqu'a un million d'etats ! 



L'historique 

Par defaut, un automate n'a pas de memoire. La notation speciale H offre un 
mecanisme pour memoriser le dernier sous-etat visite et pour le rejoindre lors 
d'une transition entrant dans le super-etat qui l'englobe. Le concept d'historique 
s' applique au niveau dans lequel le symbole Hest declare. Le symbole Hpeut etre 
place n'importe ou dans l'etat ; le coin bas gauche est la position par defaut. 

Le diagramme suivant represente un etat C qui memorise le dernier sous-etat actif. 
L'historique est initialise lors du declenchement de la transition issue de l'etat 
initial. 




Figure 276 : Exemple a" automate hierarchique. L'etat C memorise le dernier sous-etat actif. 
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La memorisation, quelle que soit la profondeur des sous-etats emboites, est 
egalement possible ; elle est indiquee par le symbole H*. Les niveaux de 
memorisation intermediates sont obtenus en placant un symbole H par niveau 
hierarchique. Dans l'exemple suivant, l'etat A memorise le dernier sous-etat actif, 
quelle que soit la profondeur d'emboitement des sous-etats. 
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Figure 277 : Le mecanisme d'historique H* permet de memoriser le dernier sous-etat actif, 
quelle que soit la profondeur d'emboitement. 

L'exemple suivant montre l'utilisation de l'historique pour la realisation d'un lave- 
vaisselle. Le cycle de lavage est decoupe en trois grandes etapes : le rinfage, le 
lavage et le sechage. A tout moment, la porte peut etre ouverte, pour rajouter par 
exemple une tasse ; des que la porte est refermee, le cycle de lavage reprend au 
point ou il a ete interrompu. 
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Figure 278 : Un etat englobant peut memoriser le dernier sous-etat actif. Le contrdle est 
transmis directement au sous-etat memorise lorsqu'une transition qui arrive sur I' etat special 

H est declenchee. 



La communication entre objets 

Les objets communiquent en echangeant des messages. A la reception d'un 
message, l'objet destinataire declenche une operation pour traiter le message. Le 
message est un concept tres general qui peut tout aussi bien representer l'appel 
de procedure, 1' interruption venant du materiel ou encore la liaison dynamique. 
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Le message est la maniere de visualiser les echanges dans les diagrammes 
d'interaction entre objets, c'est-a-dire dans les diagrammes de sequence et de 
collaboration. Ces diagrammes d'interaction montrent des cas particuliers de 
comportement au sein d'un cas d' utilisation. 

Les automates represented des abstractions du comportement du point de vue 
d'un groupe d'objets (le plus souvent une classe). Le comportement decrit par les 
scenarios est une consequence particuliere de l'etat de tous les objets qui 
collaborent au sein de ces scenarios. 

Les envois de messages entre deux objets sont visualises de maniere abstraite 
dans le formalisme des diagrammes d'etats-transitions par l'envoi d'un 
evenement entre les automates d'etats-finis des classes d'objets concernees. La 
visualisation dans les diagrammes d'etats-transitions est plus abstraite car, a un 
evenement envoye entre deux automates, correspond de nombreux envoi de 
messages entre objets. 

La syntaxe d'un envoi d'evenement vers une classe est : 
*Cible . Evenement (Arguments) 

ou la cible designe la classe des objets destinataires de l'evenement. 
La syntaxe complete d'une transition est : 
Even emen t (Argumen ts) [ Con dition] 
/Action 

*Cible . Evenement (Arguments) 

L'exemple suivant montre des fragments d' automates d'un televiseur et de sa 
telecommande. Le televiseur peut etre allume ou eteint par manipulation d'un 
interrupteur basculant. La telecommande possede un bouton-poussoir (touche 
on/off) qui, lorsqu'il est enfonce, allume ou eteint le televiseur. Le televiseur peut 
etre commande directement ou par la telecommande. 
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Figure 279 : Le mecanisme d'envoi d'evenement entre automates represente de maniere 
abstraite les echanges de messages entre les objets instances des classes associees a ces 

automates. 

Par generalisation, l'envoi d'evenement est possible vers n'importe quel 
ensemble d'objets (une classe est un cas particulier d'ensemble d'objets). Les 
formes les plus courantes sont l'envoi a tous les objets (la diffusion) et l'envoi a 
un objet particulier (le point a point). Dans le cas d'un automate qui decrit une 
classe composite, les actions peuvent faire reference directement aux operations 
declarees dans les differentes classes contenues par la classe composite. 

Creation et destruction des objets 

La creation d'un objet se represente par l'envoi d'un evenement de creation a la 
classe de l'objet. Les parametres de cet evenement permettent d'initialiser le 
nouvel objet, qui debute son existence a partir de l'etat initial decrit dans 
l'automate de la classe. L'exemple suivant montre une transition de creation qui 
immatricule un avion. En cas de crash, l'avion cesse d'exister. 
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Figure 280 : La transition de creation emmene l'objet depuis l'etat initial vers son premier 
etat de fonctionnement. L'arrivee dans l'etat final implique la disparition de l'objet. 
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La destruction d'un objet est effective lorsque le flot de controle de l'automate 
atteint un etat final non emboite. L'arrivee dans un etat final emboite implique la 
remontee a l'etat englobant, et non la fin de l'objet. 



Les transitions temporisees 

Les attentes sont par definition des activites qui durent un certain temps. Une 
attente est done naturellement rattachee a un etat plutot qu'a une transition ; elle 
se represente au moyen d'une activite d' attente. L'activite d' attente est 
interrompue lorsque l'evenement attendu a lieu. Cet evenement declenche en effet 
une transition permettant de sortir de l'etat qui heberge l'activite d'attente. Le flot 
de controle est alors transmis a un autre etat. 

L'exemple suivant illustre une sequence d'attente dans un guichet automatique 
de banque. La trappe qui accueille les depots est ouverte ; le systeme informe 
l'utilisateur qu'il dispose de trois minutes pour effectuer son depot. Si le depot 
est effectue dans les trois minutes, l'activite d'attente est interrompue par le 
declenchement de la transition vers l'etat B. En revanche, si le depot n'intervient 
pas dans le delai imparti, la transition automatique vers l'etat d'annulation est 
declenchee a la fin de l'activite d'attente. Dans tous les cas, Taction de sortie de 
l'etat d'attente referme la trappe. 
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Figure 281 : Representation d'une temporisation par combinaison d'une activite d'attente et 

d'une transition automatique. 



Les temporisations peuvent se representer au moyen d'une notation plus 
compacte, directement attachee a la transition declenchee apres le delai d'attente. 
L'evenement declencheur porte le nom generique de temporisation et le 
parametre specifie la duree de la temporisation. 

La syntaxe d'un evenement de temporisation est : 

Tempori sat ion (duree_ de_ t empori sat ion) 
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Le diagramme precedent se transforme de la maniere suivante : 
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Figure 282 : Representation d'une temporisation par une transition temporisee. 

Les automates offrent un formalisme bien adapte pour la representation des 
comportements complexes. En analyse, les diagrammes d'etats-transitions 
capturent le comportement souhaite ; durant la realisation, les automates peuvent 
s'ecrire facilement, par exemple au moyen de tables contenant les etats et les 
actions a executer lors des transitions. 

Introduction au metamodele 

Un automate represente un comportement qui resulte d' operations executees 
suite a une sequence de changements d'etat. Un automate peut etre visualise 
selon le point de vue des etats (par les diagrammes d'etats-transitions) ou selon 
le point de vue des actions (par les diagrammes d'activites). Un automate specifie 
le comportement d'une collaboration. 

L'execution d'une instance d'automate ne peut pas etre interrompue. A tout 
moment, un automate peut reagir a un evenement particulier qui l'entraine d'un 
etat stable vers un autre etat stable. L'execution de l'automate debute a partir du 
pseudo-etat initial et se poursuit, au rythme des evenements, jusqu'a ce qu'un 
pseudo-etat final, non emboite, soit atteint. 
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Figure 283 : Extrait du metamodele. Un automate est un graphe compose d'etats et de 

transitions. 

Les evenements declenchent des transitions. Le declenchement d'une transition 
entraine l'automate de l'etat source de la transition vers l'etat de destination. Au 
passage, une ou plusieurs actions peuvent etre declenchees sur un ou plusieurs 
objets. 

UML definit trois sortes d'evenements : 

• 1' evenement signal cause par un signal, 

• l'evenement appel cause par une operation, 

• l'evenement tempore! cause par l'expiration d'une temporisation. 

Le diagramme suivant represente les transitions, leurs actions et les differents 
evenements qui les declenchent. 
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Figure 284 : Extrait du metamodele. Representation des differentes sortes d'evenements. 
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Les diagrammes d'activites 



Un diagramme d'activites est une variante des diagrammes d'etats-transitions, 
organise par rapport aux actions et principalement destine a representer le 
comportement interne d'une methode (la realisation d'une operation) ou d'un cas 
d'utilisation. 

Representation des activites 

Un diagramme d'activites represente l'etat de l'execution d'un mecanisme, sous la 
forme d'un deroulement d'etapes regroupees sequentiellement dans des branches 
paralleles de flot de controle. 

Un diagramme d'etats-transitions peut egalement representer ce deroulement 
d'etapes. Toutefois, etant donne la nature procedurale de la realisation des 
operations - dans laquelle la plupart des evenements correspondent simplement a 
la fin de l'activite precedente - il n'est pas necessaire de distinguer 
systematiquement les etats, les activites et les evenements. II est alors interessant 
de disposer d'une representation simplified pour la visualisation directe des 
activites. Dans ce contexte, une activite apparait comme un stereotype d'etat. Une 
activite est representee par un rectangle arrondi, comme les etats, mais plus etire 
horizontalement. 

La figure suivante affiche les representations graphiques des activites et des 
etats, et met en evidence la simplification apportee par la representation directe 
des activites. 

E1 

do: Activite 

^ Activite 



E2 



Figure 285 : Exemple de simplification graphique par representation directe des activites. 

Chaque activite represente une etape particuliere dans l'execution de la methode 
englobante. Les activites sont reliees par des transitions automatiques, 
representees par des fleches, comme les transitions dans les diagrammes d'etats- 
transitions. Lorsqu'une activite se termine, la transition est declenchee et l'activite 
suivante demarre. Les activites ne possedent ni transitions internes, ni transitions 
declenchees par des evenements. 
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3 -La notation UML - 183 



La figure suivante represente deux activites reliees par une transition 
automatique. II n'est pas necessaire de faire figurer un nom d'evenement sur la 
transition. 

Activit6 

Transition aulomy tique 

^Ajtrc activitA^l 



Figure 286 : Representation d'une transition automatique. 



Les transitions entre activites peuvent etre gardees par des conditions 
booleennes, mutuellement exclusives. Les gardes se representent a proximite des 
transitions dont elles valident le declenchement. 



CMesurer la N 
temperature ) 

[trop froid] ./ XJtrop chaud] 



Chauffer ^ ^ Rcfroidir ^ ) 



Figure 287 : Exemple de representation des conditions. 



UML definit un stereotype optionnel pour la visualisation des conditions. Une 
condition est materialisee par un losange d'ou sortent plusieurs transitions. Le 
diagramme suivant est equivalent au diagramme precedent, si ce n'est que la 
condition est materialisee explicitement. 

(Mesurer la 
temperature 




Figure 288 : Exemple d'activite stereotypee pour representer une decision. 

Les diagrammes d'activites representent les synchronisations entre flots de 
controles, au moyen de barres de synchronisation. Une barre de synchronisation 



184 - Modelisation objet avec UML 



permet d'ouvrir et de fermer des branches paralleles au sein d'un flot d'execution 
d'une methode ou d'un cas d'utilisation. Les transitions au depart d'une barre de 
synchronisation sont declenchees simultanement. 

L'exemple suivant montre que pour refroidir, il faut simultanement arreter le 
chauffage et ouvrir les fenetres. 

C Refroidir 



f Arreter le \ / ~~ \ 

Figure 289 : Exemple de synchronisation de flots de controle paralleles a partir d'une barre 

de synchronisation. 

Inversement, une barre de synchronisation ne peut etre franchie que lorsque 
toutes les transitions en entree sur la barre ont ete declenchees. La figure 
suivante reprend l'exemple precedent et montre que la mesure de temperature est 
effectuee une fois que le chauffage est arrete et la piece aeree. 

^ chauffage ) { Mrer ) 



(Mesurer la A 
tornpdiraturc J 

Figure 290 : Exemple de fusion de flots de controle paralleles regroupes sur une barre de 

synchronisation. 

Les diagrammes d'activites peuvent etre decoupes en couloirs d'activites (comme 
une piscine est decoupee en couloirs de natation) pour montrer les differentes 
responsabilites au sein d'un mecanisme ou d'une organisation. Chaque 
responsabilite est assuree par un ou plusieurs objets et chaque activite est 
allouee a un couloir donne. La position relative des couloirs n'est pas 
significative ; les transitions peuvent traverser librement les couloirs. 
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Figure 291 : Exemple de partition d'un diagramme d'activites en couloirs d'activites. 



II est possible de faire apparaitre clairement les objets dans un diagramme 
d'activites, soit au sein des couloirs d'activites, soit independamment de ces 
couloirs. Les objets sont alors representes par des barres verticales, comme dans 
les diagrammes de sequence ; les activites apparaissent objet par objet sur la 
ligne de vie de ces objets. 

Souvent, differentes activites manipulent un meme objet qui change alors d'etat 
selon le degre d'avancement du mecanisme. Pour augmenter la lisibilite, cet objet 
peut figurer a plusieurs reprises dans les diagrammes ; son etat est alors specifie a 
chaque occurrence dans une expression entre crochets. 

Les flots d'objets sont representes par des fleches pointillees. Une fleche relie 
ainsi un objet a l'activite qui l'a cree. De meme, une fleche relie un objet aux 
activites qui le mettent en jeu. Lorsqu'un objet produit par une activite est utilise 
immediatement par une autre activite, le flot d'objets represente egalement le flot 
de controle ; il est alors inutile de representer explicitement ce flot de controle. 

Le diagramme suivant illustre les differents cas de figure evoques dans ce 
paragraphe. En particulier, l'exemple fait apparaitre un objet Commande manipule 
par differentes activites. 
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Figure 292 : Visualisation directe des objets responsables des differentes activites. 

Les diagrammes d'activites peuvent egalement contenir des etats et des 
evenements represented de la meme maniere que dans les diagrammes d'etats- 
transitions. Le diagramme suivant donne un exemple d'emploi simultane des deux 
notations. 
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Figure 293 : Exemple de representation mixte, incluant des etats et des activites. 

UML definit egalement des stereotypes pour la representation explicite des 
informations de transitions. L'envoi d'un signal se symbolise par un pentagone 
convexe relie par une fleche pointillee a l'objet destinataire du signal. L'attente 
d'un signal se symbolise par un pentagone concave relie par une fleche pointillee 
a l'objet emetteur du signal. 
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Figure 294 : Exemple de stereotypes qui presentent graphiquement I'envoi et la reception de 

signaux. 



Les diagrammes de composants 



Les diagrammes de composants decrivent les elements physiques et leurs 
relations dans l'environnement de realisation. Les diagrammes de composants 
montrent les choix de realisation. 

Les modules 

Les modules representent toutes les sortes d'elements physiques qui entrent 
dans la fabrication des applications informatiques. Les modules peuvent etre de 
simples fichiers, des paquetages du langage Ada, ou encore des bibliotheques 
chargees dynamiquement. 

Par defaut, chaque classe du modele logique est realisee par deux composants : la 
specification et le corps. La specification contient l'interface de la classe alors que 
le corps contient la realisation de cette meme classe. La specification peut etre 
generique dans le cas des classes parametrables. 
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Figure 295 : Representations graphiques des diffe rentes sortes de modules. 

La specification et le corps d'une meme classe peuvent etre superposes dans les 
diagrammes afin de rendre la notation plus compacte. Chaque corps depend alors 
implicitement de sa specification. 




Figure 296 : Representations compactes des specifications et des corps. 

En C++, une specification correspond a un fichier avec un suffixe . h et un corps 
a un fichier avec un suffixe . cpp. En Ada, la notion de module existe directement 
dans le langage sous 1' appellation de paquetage. 

Les dependances entre composants 

Les relations de dependance sont utilisees dans les diagrammes de composants 
pour indiquer qu'un composant fait reference aux services offerts par un autre 
composant. Ce type de dependance est le reflet des choix de realisation. Une 
relation de dependance est representee par une fleche pointillee qui pointe de 
l'utilisateur vers le fournisseur. 




Figure 297 : La relation de dependance permet de relier les differents composants. 

La relation de dependance peut etre specialised par un stereotype afin de preciser 
la nature des choix de realisation qui entrainent la relation de dependance. 
L'exemple suivant montre la construction d'un composant X a partir d'une liste 
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generique. La procedure It erer est un ami de X, ami etant pris au sens C++ de 
friend. 
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Figure 298 : Emploi de stereotypes pour preciser la nature des choix de realisation. 

Dans un diagramme de composants, les relations de dependance representent 
generalement les dependances de compilation. L'ordre de compilation est donne 
par le graphe des relations de dependance. 
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Figure 299 : Representation des dependances de compilation dans un diagramme de 

composants. 



Les processus et les taches 

Les taches correspondent a des composants qui possedent leur propre flot 
(thread en anglais) de controle. Les taches peuvent etre contenues par d'autres 
composants comme les unites de compilation du langage Ada. Comme pour tous 
les elements de modelisation, l'ajout de stereotypes permet de preciser la 
semantique d'un composant dynamique. Les stereotypes «Processus» et 
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«Flot» sont predefinis par UML. Plusieurs flots peuvent partager le meme 
espace d'adressage au sein d'un processus. 



Les programmes principaux 

Les points d'entree dans les applications sont identifies par l'icone suivante : 



En C++, le programme principal correspond a une fonction libre appelee main, 
stockee dans un fichier avec un suffixe . cpp. En Ada, toute procedure de 
bibliotheque peut etre designee comme programme principal. 

Le nom du programme principal est souvent utilise par l'editeur de lien pour 
nommer le programme executable correspondant a 1' application. Ceci permet, entre 
autres, de relier le modele des composants avec le modele des processus. 

Les sous-programmes 

Les sous-programmes regroupent les procedures et les fonctions qui 
n'appartiennent pas a des classes. Ces composants peuvent contenir des 
declarations de types de base necessaires pour la compilation des sous- 
programmes. En revanche, ils ne contiennent jamais de classes. 

II existe deux representations graphiques : une pour la specification des sous- 
programmes et une pour leur realisation. 




Figure 300 : Representations graphiques des specifications et corps de tdches. 




Figure 301 : Representation graphique des programmes principaux. 
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Figure 302 : Representations graphiques des specifications et realisations des sous- 
programmes. 

En Ada, il est possible de definir le corps d'un sous -programme seul: la 
specification est alors implicite et ne figure done pas dans le diagramme. 

Les sous-systemes 

Pour faciliter la realisation des applications, les differents composants peuvent 
etre regroupes dans des paquetages selon un critere logique. lis sont souvent 
stereotypes en sous-systemes pour ajouter les notions de bibliotheques de 
compilation et de gestion de configuration a la semantique de partition deja 
vehiculee par les paquetages. Les sous-systemes jouent pour les composants le 
meme role que les categories pour les classes. 

«Sous-systeme» 



Figure 303 : Representation graphique des sous-systemes a partir d'un paquetage et d'un 

stereotype. 

Les sous-systemes organisent la vue de realisation d'un systeme ; chaque sous- 
systeme peut contenir des composants et d'autres sous-systemes. Par 
convention, tout composant du modele est place soit au niveau racine, soit dans 
un sous-systeme. Les sous-systemes doivent etre vus comme de grandes briques 
pour la construction des systemes. 
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Figure 304 : Les sous-systemes peuvent etre emboites les tins dans les autres. 

La decomposition en sous-systemes n'est pas une decomposition fonctionnelle. 
Les fonctions du systeme sont exprimees du point de vue de l'utilisateur dans la 
vue des cas d' utilisation. Les cas d'utilisation se traduisent en interactions entre 
objets dont les classes sont elles-memes encapsulees par des categories. Les 
objets qui realisent les interactions sont distribues dans les differentes 
categories ; le code correspondant est stocke dans des modules et des sous- 
systemes. 
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Figure 305 : Les objets interagissent pour realiser les comportements decrits 
fonctionnellement dans les cas d'utilisation. 

Le sous-systeme est, dans la vue physique, l'equivalent de la categorie dans la 
vue logique. La figure suivante montre la correspondance entre les deux vues. 
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Figure 306 : Extrait du metamodele montrant la correspondance entre la vue logique et la 

vue physique. 
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Un sous-systeme est un moyen de gerer la complexite par 1' encapsulation des 
details. Les sous-systemes possedent une partie publique et une partie privee. 
Sauf indication contraire explicite, tout module place dans un sous-systeme est 
visible de l'exterieur. 

Les sous-systemes peuvent dependre d'autres sous-systemes et de composants. 
De meme, un composant peut dependre d'un sous-systeme. 
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Figure 307 : Relations de dependance entre differents types de composants et sous-systemes. 



Integration avec les envlronnements de developpement 

Les sous-systemes n'existent pas en tant que tels dans tous les environnements 
de developpement de logiciel. II appartient alors a l'utilisateur de mettre en place 
une structure a base de repertoires et de fichiers pour les realiser physiquement. 
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Figure 308 : Realisation d'un sous-systeme a partir d'une structure de repertoires et de 

fichiers. 

Dans cette optique, il est particulierement judicieux de se servir de la notion de 
sous-systeme comme d'un point d'integration avec les outils d'analyse et de 
conception de logiciels, les systemes de compilation et les systemes de gestion 
de versions et de configurations. 

Chaque sous-systeme est materialise par un repertoire qui contient des fichiers ; 
ces fichiers correspondent aux differents composants contenus par le sous- 
systeme. Le sous-systeme contient en plus les differents fichiers necessaires a la 
compilation, a la documentation et au test des composants. L'integration avec les 
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systemes de compilation permet d'associer la notion de bibliotheque de 
programmes a la notion de sous-systeme. L'integration avec un gestionnaire de 
configurations conduit a la construction de systemes par combinaison de 
bibliotheques de compilation. L'integration peut encore etre enrichie par un 
gestionnaire de versions, idealement a deux niveaux de granularite. II devient 
alors possible de construire un systeme par combinaison de versions de sous- 
systemes (exprimees sous la forme de bibliotheques de programmes), elles-memes 
composees de versions de composants. 



Les diagrammes de deploiement 

Les diagrammes de deploiement montrent la disposition physique des differents 
materiels (les noeuds) qui entrent dans la composition d'un systeme et la 
repartition des programmes executables sur ces materiels. 

Representation des noeuds 

Chaque ressource materielle est representee par un cube evoquant la presence 
physique de l'equipement dans le systeme. Tout systeme est decrit par un petit 
nombre de diagrammes de deploiement ; souvent un seul diagramme suffit. 




Figure 309 : Representation graphique des noeuds. 

La nature de l'equipement peut etre precisee au moyen d'un stereotype. 
L'exemple suivant propose trois stereotypes pour distinguer les dispositifs, les 
processeurs et les memoires. Au besoin, l'utilisateur a la possibilite de definir 
d'autres stereotypes. 



Modem 
Dispositif>|> 




Figure 310 : Exemples de stereotypes de nceud. 



La distinction entre un dispositif et un processeur depend fortement du point de 
vue. Un terminal X sera vu comme un dispositif par l'utilisateur du terminal alors 
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qu'il correspondra a un processeur pour le developpeur du serveur X qui 
s'execute sur le processeur embarque dans le terminal X. 

Les differents noeuds qui apparaissent dans le diagramme de deploiement sont 
connectes entre eux par des lignes qui symbolisent un support de communication 
a priori bidirectionnel. La nature de ce support peut etre precisee au moyen d'un 
stereotype. 




— Connection ~ 




Figure 311 : Representation graphique des connexions entre noeuds. 



Les diagrammes de deploiement peuvent montrer des classes de noeuds ou des 
instances de nceuds. Comme dans les autres types de diagrammes, la distinction 
graphique entre les classes et les objets est realisee en soulignant le nom de 
l'objet. L'exemple suivant montre le diagramme de deploiement d'un systeme de 
gestion des acces d'un batiment. 
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Figure 312 : Exemple de classes dans un diagramme de deploiement. 



La presence d' informations de multiplicite et de role confirme que le diagramme 
precedent represente des classes de nceuds. Le diagramme montre que le systeme 
est constitue d'un serveur autour duquel gravitent des PC pilotant l'ouverture et 
la fermeture de portes. Le nombre de PC n'est pas precise. En revanche, il apparait 
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que chaque PC peut etre le maitre de 10 portes au plus. Trois terminaux X jouent 
le role de console pour acceder au systeme ; une imprimante est reliee au serveur. 

Le diagramme decrit egalement la nature des liens de communication entre les 
differents noeuds. Le serveur et les PC sont relies par une liaison RNIS ; les 
terminaux X et le serveur communiquent via TCP/IP. La nature de la connexion 
des autres noeuds n'a pas ete precisee. 

Les noeuds qui correspondent a des processeurs du point de vue de 1' application 
- le stereotype de processeurs n'apparait pas obligatoirement dans les 
diagrammes de deploiement - portent egalement le nom des processus qu'ils 
hebergent. Le serveur execute un systeme de gestion de bases de donnees ; les 
PC hebergent le logiciel de pilotage dedie a la commande et au controle des 
portes. Le nom de ces processus permet de faire le lien entre le diagramme de 
deploiement et le diagramme des composants. Chaque processus nomme dans le 
diagramme de deploiement execute un programme principal du meme nom, decrit 
dans le diagramme des composants. 
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Nom 







Figure 313 : Le nom des processus et des programmes principaux permet de faire le lien 
entre les diagrammes de deploiement et de composants. 

Les diagrammes de deploiement peuvent egalement montrer des instances de 
noeuds (reconnaissables au nom souligne). Le diagramme suivant nous renseigne 
ainsi sur la situation precise au niveau du site d'implantation du systeme. II 
apparait que les portes 6, 7, 8 et 9 sont pilotees par le PC 4. 
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Figure 314 : Exemple d'objets dans un diagramme de deploiement. Les noms des objets sont 
soulignes afin de distinguer les objets des classes. 



4 

Encadrement 
des projets objet 



La presence d'un processus de developpement formalise, bien defini et bien gere, 
est un facteur de reussite d'un projet. Un processus est stable si ses 
performances futures peuvent etre predites statistiquement 18 . 

UML etant avant tout un langage de modelisation elle ne definit pas un 
processus de developpement particulier. Neanmoins, elle peut servir de notation 
pour differentes approches methodologiques basees sur les objets. 

L'objectif de ce chapitre est de presenter les grandes lignes de l'encadrement des 
projets objet au travers d'un cadre methodologique generique proche de celui 
decrit par Objectory 4.0 19 . 

II appartiendra a chaque projet ou organisation de raffiner ce cadre en fonction de 
ses besoins. 



Deming W. E. 1982, Quality, Productivity, and Competitive Position. 
Massachusetts Institute of Technology Center for Advanced Engineering Study, 
Cambridge, MA. 

19 Rational Software Corporation 1996, Rational Objectory Process - 
Introduction. 
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Caracterisation du logiciel 



Ce chapitre a pour objet de caracteriser le logiciel, de mettre en evidence l'origine 
des difficultes liees a son developpement et d'esquisser les mesures a prendre 
pour les maitriser. 

La crise du logiciel 

La formule est nee il y a trente ans 20 pour decrire la limite des technologies 
disponibles et l'incapacite a maitriser le logiciel qui en resulte. Bien sur, au cours 
de ces trente dernieres annees, de nombreux progres ont ete realises, mais le 
logiciel est toujours en crise. II est probable, comme le suggere Grady Booch, qu'il 
ne s'agit pas d'une crise mais plutot d'un etat permanent. 

Les methodes objet ont pris le relais des techniques structurees traditionnelles ; 
les logiciels objet sont plus extensibles, plus proches des utilisateurs, plus faciles 
a maintenir, mais ils restent toujours difficiles a realiser. 

II faut bien le dire, une des raisons de la crise du logiciel est la fuite en avant vers 
la complexite des applications. La complexite intrinseque de chaque nouvelle 
generation de systeme est plus grande de sorte que les solutions techniques qui 
etaient adaptees pour la generation precedente arrivent a leurs limites pour la 
generation suivante. La crise du logiciel ne connait pas de fin. 

II existe plusieurs types de logiciels qui peuvent chacun se caracteriser par les 
contraintes qu'ils placent sur le processus de developpement. 

Les categories de logiciels 

Les logiciels amateurs constituent la premiere categorie. Le terme amateur ne doit 
pas etre pris dans un sens pejoratif : il designe tout logiciel qui n'a pas d'impact 
economique significatif. Ce type de logiciel est generalement developpe par des 
individus au sein de groupes qui partagent des centres d'interet communs, 
comme par exemple les radioamateurs ou les astronomes amateurs. Les logiciels 
developpes par les etudiants tombent egalement dans cette categorie. 

La deuxieme categorie regroupe les logiciels jetables, dits aussi logiciels 
consommables, comme les traitements de texte ou les tableurs. Ce type de logiciel 
ne coute pas tres cher a 1' achat (quelques milliers de francs tout au plus) et son 
remplacement par un logiciel equivalent ne risque pas de mettre en peril l'equilibre 
financier de l'entreprise qui en a fait l'acquisition. Le point de vue du fabricant de 



1U Buxton J. N. & Randell B. £ds) 27-31 Octobre 1969, Software Engineering 
Techniques. Report on a Conference Sponsored by the NATO Science 
Committee, Rome, Italy. 
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ce type de logiciel est quelque peu different, et cela d'autant plus que la diffusion 
de ce type de logiciel est large. Une fois le logiciel en exploitation chez des milliers 
de clients, eventuellement du monde entier, il n'est guere aise de proposer des 
corrections de defauts, d'autant que les revenus derives des contrats de 
maintenance sont faibles. II faut done maintenir un equilibre difficile entre qualite 
du produit, cout de developpement et diffusion. L'objectif de qualite a moindre 
cout est difficile a tenir, mais imperatif pour les produits a marge faible et grande 
distribution. Internet et le principe du shareware simplifient enormement la 
diffusion de ce type de logiciel, mais ne resorbent pas l'imperatif de qualite. 

La troisieme categorie comprend les logiciels essentiels au fonctionnement d'une 
entreprise et qui ne peuvent etre echanges facilement : ils ont ete construits pour 
une tache donnee et sont le fruit d'un investissement non negligeable. Ce type de 
logiciel exige un comportement fiable, sur et previsible : leur defaillance peut 
entrainer la chute de l'entreprise qui les utilise. Ils sont presents a la fois dans les 
secteurs industriels et tertiaires, par exemple pour piloter un autocommutateur ou 
pour gerer une salle des marches. La grande complexite de ces logiciels - plus 
precisement de ces systemes logiciels - provient d'une part de la complexite 
intrinseque liee au domaine des applications et d' autre part de la complexite des 
environnements d'execution, souvent heterogenes et distribues. Leur 
maintenance evolutive devient de plus en plus difficile car chaque modification 
rend le logiciel plus confus. Les informaticiens subissent alors le poids du passe, 
souvent jusqu' a un point de rupture qu'il est essentiel d'anticiper. La triste realite 
est que l'entropie des logiciels est a l'image de l'entropie de l'univers : elle ne 
cesse de croitre. De ce point de vue, un processus de developpement doit limiter 
le desordre logiciel. 

La derniere categorie de logiciels englobe les systemes vitaux, e'est-a-dire ceux 
dont depend la vie d'etres humains. Ces systemes se rencontrent dans les 
domaines du transport de l'armement et de la medecine. Les contraintes 
d' exploitation de ces logiciels n'ont absolument rien a voir avec les categories 
precedentes. Un dysfonctionnement ne se chiffre plus en argent, mais en vies 
humaines. 

La complexite des logiciels 

Les informaticiens, de maniere generate, ont un grave defaut. Ils ne savent pas 
faire simple. D'un autre cote, faire simple est extremement difficile. 

Faire simple, e'est par exemple apprendre a encapsuler la complexite ; e'est aussi 
lutter contre le plaisir que procure le maniement des arcanes d'un langage de 
programmation. Faire simple, e'est egalement apprendre a faire semblant que e'est 
simple, e'est creer l'illusion de la simplicite. 
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L'informaticien doit apprendre a imiter la nature qui, dans ses constructions les 
plus elementaires comme les plus complexes, cherche toujours l'equilibre stable, 
la consommation d'energie minimale, loin du caprice ou du superflu. 

Trop souvent, l'elaboration des logiciels reste une activite parcellaire et 
dispersee. Si l'informaticien construisait des meubles, il commencerait par planter 
des glands, debiterait les arbres en planches, creuserait le sol a la recherche de 
minerai de fer, fabriquerait une forge pour faire ses clous et finirait par assembler 
le tout pour obtenir un meuble. Ce mode de fabrication engendre une large 
dispersion des efforts et requiert la maitrise d'une trop grande palette de 
competences. Durant les siecles passes, nos ancetres ont appris a specialiser les 
activites humaines et c'est ainsi que certains specialistes savent comment faire 
pousser les arbres alors que d'autres connaissent les secrets de fabrication des 
clous. L'avantage immediat de cette approche est que les autres personnes 
peuvent se concentrer sur leur propre domaine de connaissance, par exemple la 
fabrication des meubles. Un mode de developpement qui repose sur les epaules 
de quelques programmeurs heroiques, de gourous et autres magiciens du logiciel, 
ne constitue pas une pratique industrielle perenne et reproductible. 

La formalisation du processus de developpement procede de cette constatation. 
Les activites mises en oeuvre lors de l'elaboration du logiciel doivent etre decrites, 
expliquees, motivees : la connaissance et le savoir-faire informatique peuvent 
alors se propager autrement que de bouche de druide a oreille de druide 21 . Un 
processus decrit l'enchainement des activites de l'equipe de developpement ; il 
dirige les taches de chaque individu ainsi que celles du groupe. Le processus 
definit des points de mesures et des criteres pour controler et mesurer les 
produits et les activites du projet. 

Malheureusement, la formalisation du processus de developpement ne s' applique 
que partiellement au domaine informatique. Contrairement a l'ebenisterie, 
l'informatique est un domaine de connaissance tres jeune et pauvre en savoir- 
faire transmissibles. De plus, le niveau de formalisation du savoir-faire 
informatique est tres faible. Avant de vouloir propager l'experience, il faut 
d'abord savoir la decrire, la representee la modeliser. 

Cela revient egalement a dire que l'informatique est un metier qui s'apprend 
comme les autres metiers : il n'est pas possible de s'improviser informaticien. Une 
entreprise qui recherche un specialiste de l'informatique doit done rechercher un 
ingenieur informaticien plutot qu'un specialiste de la chimie ou du textile. 

Origines de la complexity des logiciels 

II ne suffit pas de jeter la pierre aux informaticiens : de plus en plus, la 
problematique qui leur est soumise est complexe de par la nature meme du 



Gosciny, Uderzol961, Asterix le Gaulois, Dargaud. 
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domaine des applications. Avec la meilleure volonte du monde, cette complexite 
ne peut etre reduite par 1'informaticien. En revanche, elle peut etre canalisee, 
confinee dans des espaces clos faiblement couples. Par une segmentation 
judicieuse de l'espace des etats, la caracterisation du comportement des systemes 
discrets - que sont les programmes - est facilitee. 

De la meme maniere, la complexite liee a l'environnement informatique, c'est-a-dire 
aux methodes, aux langages, aux systemes d' exploitation, etc, peut et doit etre 
minimisee le plus possible : il faut eviter les solutions moins onereuses mais plus 
complexes. 

En amont de ces problemes de complexite, il faut insister sur l'infinie flexibilite du 
logiciel qui est a la fois son plus grand avantage et son plus grand defaut. II est 
extremement facile d'ecrire une ligne de programme ; il est plus difficile de la 
mettre au point. II est tout aussi facile de modifier une ligne dans un programme ; 
il est infiniment plus difficile de garantir que le programme continuera de 
fonctionner correctement. 

Consequence de la complexite 

Du fait de la complexite liee a 1' elaboration des logiciels, il y a fort peu de chances 
qu'un logiciel soit exempt de defauts. Au contraire, le risque de deficience grave 
est eleve. 

Les defauts logiciels, les bogues, sont comme les couacs en musique 22 . Les 
meilleurs musiciens ne sont pas a l'abri d'un couac ; ce qu'ils font est difficile et 
assurer une qualite constante, sur une longue duree, Test aussi. L'informaticien 
est confronte au meme probleme, quelles que soient ses competences ; il n'est 
pas a l'abri d'un couac. Les logiciels sont ecrits par des humains, les humains 
sont faillibles, les logiciels aussi. 

La mise au point des logiciels est lente et chaotique, et le cout de maintenance est 
disproportionne. Les techniques de test et de validation permettent de degager 
des chemins d'execution securises : suivis a la lettre, ils permettent de garantir un 
niveau de confiance raisonnable dans le logiciel. 

Tous les defauts n'ont pas les memes consequences. Les defauts d'analyse se 
traduisent par des logiciels qui ne satisfont pas leurs utilisateurs. Les defauts de 
conception generent des logiciels lourds a manier, trop lents ou peu efficaces. Les 
defauts de realisation induisent des comportements non prevus. Tout defaut est 
indesirable ; ceux introduits dans les activites en amont restent cependant les 
plus difficiles a corriger. 



Adda J.-L., communication privee. 
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La crise de logiciel est le fruit de notre incapacite a maitriser les defauts du 
logiciel. Le resultat de cette crise est le cout astronomique des applications 
complexes. 

La portee de I'approche objet 

Le developpement d'une application peut etre divise en plusieurs grandes 
parties : elles s'enchainent de maniere sequentielle au sein d'un cycle de vie en 
cascade ou elles se distribuent sur les differentes iterations d'un cycle de vie 
iteratif. 

De maniere generale, quelle que soit la maniere de proceder, lineairement ou 
iterativement, selon une approche structuree ou objet, le developpement d'une 
application repond a quatre questions : 



Application =Quoi + Dans quel domaine + Comment + Avec quelles competences 



Ces questions correspondent a differents points de vue et concernent differents 
intervenants. Elles peuvent etre etudiees selon des techniques variees, mais 
doivent dans tous les cas etre consideres pour developper une application : 

• Quoifaire ? La reponse est exprimee par l'utilisateur qui decrit ce qu'il attend 
du systeme, comment il entend interagir avec lui et quels sont les differents 
intervenants. II s'agit d'une description fonctionnelle qui ne rentre pas dans 
les details de la realisation : le quoifaire est purement descriptif. 

• Dans quel domaine ? La reponse doit decrire le domaine (l'environnement) 
dans lequel l'application va exister et preciser quels sont les elements 
pertinents dans ce domaine pour l'application. L'etude du domaine est le fruit 
d'une analyse, totalement deconnectee de toute consideration de realisation. 
Le domaine est analyse par un analyste et doit pouvoir etre compris par un 
utilisateur. 

• Comment ? II faut le determiner lors de la conception. Le comment est le fruit 
de l'experience et du savoir-faire du concepteur. La conception est l'art de 
rendre possible les desirs de l'utilisateur - exprimes dans le quoi faire - en 
considerant le domaine de l'application et en tenant compte des contraintes 
de realisation. 

• Avec quelles competences ? II faut determiner tout ce qui est necessaire a la 
fabrication de l'application. Ce point repose sur des competences techniques 
pour le developpement des classes, des objets et des mecanismes, sur des 
competences d'animation pour l'encadrement des equipes et sur des 
competences d'organisation pour assurer la logistique generale. 
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L'approche objet repond a ces questions, selon trois regards differents : l'analyse 
objet, la conception objet et la programmation objet. 




Figure 315 : L'approche objet porte trois regards differents sur les systemes. 

L'analyse objet 

L'analyse remonte de la consequence vers le principe : elle essaie de comprendre, 
d'expliquer et de representer la nature profonde du systeme qu'elle observe. 
L'analyse ne se preoccupe pas de solutions mais de questions ; elle identifie le 
quoifaire et l'environnement d'un systeme, sans decrire le comment qui est le 
propre de la conception. 

L'analyse commence par la determination du quoifaire, c'est-a-dire des besoins 
de l'utilisateur. Bien souvent, l'utilisateur n'est pas capable d'exprimer clairement 
ses attentes, de sorte que le cahier des charges n'est qu'une representation 
approximative de ses besoins reels. La presence d'un imposant cahier des 
charges n'est pas toujours de bon augure. Sa qualite depend tres fortement de 
la technique employee pour son elaboration. Trop souvent, les cahiers des 
charges sont touffus, confus, contiennent des points contradictoires et ne 
refletent pas les vrais besoins des utilisateurs. L'experience montre que la 
technique des cas d'utilisation (use cases) se prete bien a la determination des 
besoins de l'utilisateur. 

L'analyse se poursuit par la modelisation du domaine de 1' application, c'est-a-dire 
par 1' identification des objets et des classes qui appartiennent fondamentalement 
a l'environnement de V application, et par la representation des interactions entre 
ces objets. L'analyse rend compte de la structure statique au moyen des relations 
entre les classes et des interactions entre les objets au moyen des messages. II 
n'existe pas d'ordre preferentiel dans l'elaboration des differents types de 
diagrammes : ils sont souvent construits simultanement. Parmi les nombreux 
diagrammes definis par UML, ceux qui montrent des elements de la vue logique 
peuvent etre utilises en analyse, en particulier : 

• les cas d'utilisation, 
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• les specifications de classes et d'objets, 

• les diagrammes de collaboration, 

• les diagrammes de sequence, 

• les diagrammes de classes, 

• les diagrammes d'etats-transitions. 

Cette liste n'est pas limitative et chaque projet est libre d'utiliser d'autres 
techniques pour parfaire 1' analyse de son probleme. En particulier, les approches 
cognitives et systemiques apportent souvent un eclairage interessant et 
complementaire de la modelisation objet. 

L' assise sur les elements du monde reel facilite le depart de la demarche car elle 
concentre la pensee sur des elements concrets. Elle doit imperativement etre 
poursuivie par une demarche d' abstraction qui vise a faire oublier les 
contingences du monde reel et a determiner les concepts fondateurs qui sont a 
leurs origines. Si la reflexion se focalise trop sur l'existant, les risques de 
reproduire une solution au lieu d'identifier le probleme pose sont grands (voir 
plus loin le paragraphe sur la place de l'informatique ou le choc des cultures). 

L' analyse est l'antithese de la conformite. L' analyse est souvent surprenante car 
elle demande de changer de point de vue, d' oublier ce qui est connu, ce qui 
s'impose de prime abord, afin de trouver l'essentiel, la nature cachee des choses. 
Le propre de 1' analyse est de trouver une description a laquelle personne n'avait 
pense jusqu'alors, mais qui une fois determinee s'impose au point d'etre 
evidente. 

Pour prendre une image, analyser c'est regarder un point, un cercle, une ellipse, 
une droite, deux droites secantes, une hyperbole et une parabole et reconnaitre 
que toutes ces formes peuvent etre obtenues par l'intersection d'un plan et d'un 
cone. Dans ce cas, le principe generateur peut etre exprime par une equation de la 
forme ax 2 + by 2 + 2cx + 2dy + e = Q Cette representation est 
econome car elle decrit l'essentiel. L'analyse va a l'essentiel et recherche un 
modele generique plus abstrait. 

La consequence immediate d'une analyse bien menee est toujours une grande 
economie dans la realisation qui s'ensuit, en vertu de la dichotomie (essence, 
manifestation) sous-tendu par l'approche objet. L' identification du principe 
generateur permet de realiser en une seule fois ce qui se manifeste generalement 
sous plusieurs formes, puis de l'instancier pour obtenir les differentes 
manifestations desirees, voire souvent d'autres manifestations non encore 
presentes dans le domaine. 

Parallelement a l'analyse de l'environnement, se deroule parfois une analyse de 
l'existant et des contraintes de realisation. L'objet de cette analyse est de 
comprendre parfaitement les caracteristiques et les contraintes de 
l'environnement de realisation afin de pouvoir prendre des decisions motivees et 
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reflechies lors de la conception. Cette analyse est le seul moyen de prendre en 
compte de maniere realiste les choix de realisation qui peuvent etre imposes a un 
projet, avant meme la conception. Cette situation est malheureusement trop 
courante en informatique. Les informaticiens doivent resoudre un probleme a 
partir d'un fragment de solution ! 

Au passage a la conception, il faut prendre garde a ne pas perdre la vue 
d' analyse. La perte de cette vue est la consequence de l'enrichissement des 
modeles durant la conception. Comme il a ete dit plus haut, la conception apporte 
des informations complementaires qui viennent enrichir les descriptions 
effectuees en analyse. La tentation est forte de partir des diagrammes obtenus en 
analyse et de rajouter l'information de conception dans ces diagrammes. 
L' analyse se fond alors progressivement dans la conception et les diagrammes ne 
montrent plus les objets du domaine mais le comment. La situation est souvent 
autrement complexe car les modeles subissent des transformations qui sont plus 
que de simples enrichissements ; un filtrage ne suffit pas pour retrouver la vue 
d' analyse. 

II n'existe pas de solution simple au probleme de la transformation des modeles, 
en particulier de la transformation bidirectionnelle ; lorsque les eclaircissements 
de la conception peuvent entrainer des modifications de 1' analyse par effet 
retroactif. UML definit le concept de trace entre elements de modelisation, y 
compris d'un modele a l'autre, de sorte qu'il est possible d'enregistrer l'histoire 
de ces elements. 

La conception objet 

Comme 1' analyse et la conception, la conception et la realisation se chevauchent 
en partie. II est rare de savoir comment tout faire : pour cette raison il faut essayer 
des techniques alternatives, comparer les resultats puis choisir en faisant des 
compromis. La conception et la realisation se completent. La conception a besoin 
d' experimenter, la realisation a besoin de principes directeurs. 

Afin de maintenir le plus longtemps possible les benefices de l'abstraction, la 
conception est generalement subdivisee en deux etapes : une etape logique 
independante de l'environnement de realisation et une etape physique qui se 
preoccupe de l'ordonnancement des ressources et des particularites des langages 
de programmation ou de l'environnement d' execution. 

La conception est souvent consideree, a tort, comme un simple enrichissement 
des resultats obtenus durant l'analyse. II s'agit la d'une vision fortement 
reductrice qui ignore tout simplement que la conception est le temps de la mise en 
oeuvre du savoir-faire. Ce savoir-faire peut etre interne au projet ou acquis a 
l'exterieur sous la forme d'outils, de composants reutilisables ou plus largement 
de cadres de developpement. L'emergence des patterns (les patterns et les 
frameworks sont decrits plus loin) marque une avancee dans la formalisation du 
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savoir-faire objet, independamment des langages de programmation et de leurs 
subtils arcanes. 

La conception debute par la determination de l'architecture du logiciel, c'est-a- 
dire par l'elaboration des structures statiques et dynamiques qui serviront de 
charpente pour 1' ensemble du developpement. L'architecture definit la forme 
generate de 1' application ; de sa qualite dependent le developpement et 
revolution du logiciel. L'architecture est la consequence de decisions 
strategiques arretees lors de la conception et de decisions tactiques prises en 
cours de realisation. 

Se donner une strategie informatique, c'est considerer le logiciel comme un 
element determinant du developpement de l'entreprise ; c'est aussi chercher a 
s'assurer une avance technologique par des choix d' architecture qui depassent le 
cadre des besoins immediats, lies a une application particuliere. 

Se donner une strategie informatique, c'est par exemple choisir : 

• I 'internationalisation, autrement dit, concevoir le logiciel de telle maniere que 
le dialogue avec l'utilisateur puisse etre mene dans toutes les langues ; 

• la reutilisation qui n'est pas le fruit du hasard, mais le resultat d'une 
adhesion forte de toute une organisation, depuis la definition de la ligne de 
produits jusqu'au developpement de ces produits ; 

• Vunicite de langage pour l'ensemble des developpements (Ada dans le cas 
du ministere de la defense americain) ; 

• I'independance par rapport aux dispositifs d'affichage, autrement dit, le 
decouplage entre 1' information a afficher et la maniere de l'afficher ; 

• la portability des sources, voire des executables, qui reduit notablement les 
couts de developpement et surtout de maintenance dans le cas d'un 
developpement multicibles. 

• la generalisation des mecanismes de communication entre objets qui permet 
de rendre transparente la localisation des objets et ainsi de faciliter la 
distribution des applications et de leurs composants. 

La conception est le domaine du compromis. II n'existe pas de solution toute 
blanche ou toute noire : la verite est toujours quelque part dans le gris. Les 
decisions tactiques couvrent toutes les activites qui guideront la recherche de 
cette verite dans l'effort de developpement au jour le jour. Elles contiennent par 
exemple les elements suivants : 

• la generalisation d' abstractions et de mecanismes pour les tdches 
ancillaires, autrement dit, tous les composants largement reutilisables dans 
les programmes, comme les dates, les chaines de caracteres, les structures de 
donnees de base, les algorithmes de tri, etc. ; 
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• le traitement des erreurs qui peut etre effectue par des exceptions ou par des 
statuts exprimes sous la forme de valeurs entieres. L'exception ne peut etre 
ignoree, mais son traitement obscurcit le code normal. Le statut d'erreur est 
simple a mettre en ceuvre mais il peut etre ignore : le traitement de l'erreur n'est 
alors pas garanti ; 

• la gestion de la memoire dynamique qui peut etre effectuee par le 
programmeur ou automatisee par l'environnement d'execution ; 

• la communication entre processus qui peut reposer sur des liaisons point-a- 
point, multi-points ou par diffusion. Elle peut etre assuree par des mecanismes 
ad hoc ou inscrite dans un schema general d'integration d'application comme 
Corba ou ActiveX ; 

• le choix des modes de communication qui inclut la forme et la nature des 
messages et les differents modes de synchronisation : synchrone, semi- 
synchrone, derobante, minutee, asynchrone, etc ; 

• la presentation des messages utilisateur afin de rendre toutes les interactions 
avec l'utilisateur le plus homogenes possible ; 

• les langages de programmation qui sont compiles ou interpretes et 
presentent des points forts et des limites. Les langages compiles permettent 
d'ecrire des programmes plus fiables, les langages interpretes apportent plus 
de souplesse lors du developpement. Dans certains cas, il peut etre 
interessant de melanger differents langages au sein de la meme application ; 

• le choix des structures de donnees et des algorithmes qui sont encapsules 
dans les objets afin de decoupler la specification de la realisation des classes ; 

• V optimisation du reseau de relations qui reflete les besoins de 
communication de l'utilisateur. Le concepteur peut etre amend a modifier ce 
reseau pour diverses raisons : optimiser la vitesse des acces, prendre en 
compte des contraintes particulieres de realisation, comme 1' absence de lien 
bidirectionnel dans les langages de programmation de troisieme generation ; 

• la mutation de certaines relations de generalisation parce que l'heritage 
multiple n'est pas disponible dans le langage de programmation utilise ou 
encore parce que la forme de generalisation recherchee doit etre dynamique 
alors que l'heritage est statique ; 

• la mise en ceuvre de composants reutilisables dans le cadre de deux realites ; 
la programmation avec la reutilisation et la programmation pour la reutilisation. 
La premiere forme de reutilisation consiste a incorporer un composant existant 
et ainsi a accelerer un developpement en cours. La deuxieme forme 
s'apparente plus a un investissement : le cout est immediat et les benefices ne 
sont percus que plus tard. 

L'effort developpe en conception est plus ou moins important selon la nature de 
l'application et la richesse de l'environnement de realisation. II est de plus en plus 
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possible d'effectuer un transfert de complexite des applications vers les 
environnements, grace a une factorisation des elements et des mecanismes 
communs. C'est le cas dans les families d' applications bien ciblees dans un 
domaine donne, comme les logiciels clients qui interagissent avec des serveurs de 
bases de donnees. Inversement, plus une application est technique, plus elle 
interagit avec des materiels particuliers et plus 1' effort de conception est 
important. 

Les outils RAD - developpement rapide d' applications - proposent une voie bien 
tracee. Tout comme avec les frameworks, il faut suivre les regies du jeu fixees a 
l'avance : au benefice de la simplicite mais au detriment de l'originalite. Toutes les 
applications finissent par se ressembler, ce qui est bien et mal a la fois. Le travers 
des outils RAD est d'encourager a faire vite et salement - quick and dirty - 
plutot que vite et bien. 

Curieusement, le RAD est un melange de genie logiciel dans sa conception et 
d'horreur informatique dans son utilisation. Ceci est la consequence d'une vision 
a court terme des utilisateurs pour qui seul 1' aspect rapidite compte bien souvent. 
Comme le RAD n'encourage pas particulierement la modularite et les abstractions 
en couches, tres rapidement - c'est le cas de le dire - le code d' interface 
utilisateur et le code de 1' application se retrouvent intimement melanges. Le 
logiciel construit de cette maniere est difficile a maintenir et quasiment impossible 
a reutiliser pour une autre application. 

Le propre de la conception est de rechercher l'equilibre entre vitesse de 
realisation et possibilite de reutilisation, ouverture et solution cle en main, vision 
a court terme (la tactique) et vision a long terme (la strategie). 

La programmation objet 

La programmation objet est le dernier maillon de la chaine objet, apres 1' analyse et 
la conception. La programmation dans un langage objet est la maniere la plus 
commode de traduire une conception objet en un programme executable par une 
machine. II est egalement possible d'utiliser un langage non objet, mais ceci 
impose une charge de travail supplementaire au programmeur qui doit simuler les 
constructions objet. 

Parallelement aux vrais langages objet, comme Smalltalk ou Java, il est possible de 
trouver des langages ou des environnements a teinture objet, par exemple Visual 
Basic de Microsoft ou encore Powerbuilder de Powersoft ; d'une certaine maniere 
ils permettent de faire de l'objet en douceur, sans s'en rendre compte 23 . 

Les langages de programmation objet sont en majorite des langages 
algorithmiques et structures. Ils offrent au moins les concepts de classes, 
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d'objets, d'heritage, de liaison dynamique et d'encapsulation. Bertrand Meyer 
insiste tout particulierement sur la gestion automatique 24 de la memoire. Eiffel, 
Smalltalk et Java sont pourvus d'un systeme de ramasse-miettes qui affranchit le 
programmeur du difficile, voire insurmontable, probleme de liberation de la 
memoire dynamique. La principale qualite des langages objet est de reduire le 
decalage entre la maniere de penser du programmeur et le langage fruste compris 
par l'ordinateur. II existe toutefois de grandes variations syntaxiques entre les 
differents langages objet selon qu'ils sont une extension conservatrice comme 
C++ ou une innovation totale comme Smalltalk. 

Le choix d'un langage de programmation objet est souvent dicte par la culture 
informatique de l'entreprise. Jusqu'a present, l'informatique technique penchait 
plutot pour C++ alors que le monde de la gestion manifestait un interet croissant 
pour Smalltalk ou les solutions semi-objet evoquees precedemment. L'annee 96 a 
ete marquee par le deferlement du langage Java developpe par Sun : il suscite un 
interet tres large de la part de 1' ensemble de la communaute informatique. 

II existe de nombreux langages de programmation objet dont les principaux sont 
decrits ici dans leurs grandes lignes : 

• Ada est un langage de programmation de haut niveau concu pour reduire les 
couts de developpement exorbitants auxquels le ministere de la defense 
americain devait faire face dans les annees 70. Ada a ete normalise une 
premiere fois en 1983 par 1' ANSI. Apres une decennie d' utilisation, le langage 
Ada a ete ameliore par l'ajout de constructions objet et sa deuxieme mouture, 
standardisee en 1995, en fait un langage objet a part entiere. Ada 83 est le 
langage du genie logiciel ; Ada 95 est le langage du genie logiciel objet. 

• C++ est un langage objet hybride concu par Bjarne Stroustrup dans les 
annees 80 : c'est une extension du langage C. C++ corrige le C en rajoutant le 
typage fort, les classes, la surcharge et la liaison dynamique. Sa syntaxe reste 
touffue comme celle du C et rend C++ difficile a mettre en oeuvre. 

• Eiffel est un langage objet volontairement simple, a la syntaxe tres propre. II a 
ete concu par Bertrand Meyer dans les annees 80. Eiffel se distingue des 
autres langages objet par la place qu'il accorde a la notion de programmation 
par contrat ; c'est ainsi le seul langage qui prenne en compte le principe de 
substitution dans sa syntaxe. 

• Java est le dernier-ne des langages objet. II s' inspire de C++ pour la syntaxe et 
de Smalltalk pour la machine virtuelle, tout en restant comme Eiffel 
volontairement simple. Initialement concu pour la programmation des 
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assistants electroniques (personal digital assistant), le langage Java a ete 
propulse sur le devant de la scene par sa forte complementarite avec Internet. 

• Smalltalk est le langage objet par excellence : en Smalltalk, tout est objet, y 
compris les classes elles-memes. Smalltalk a ete concu dans les annees 70 au 
PARC (le centre de recherche de Xerox a Palo Alto). Depuis 1980, Smalltalk est 
accompagne d'un environnement de developpement sophistique et d'une 
grande collection de classes predefinies. Du fait de sa souplesse d'emploi et 
de sa simplicite, Smalltalk connait actuellement un regain d'interet pour la 
creation de systemes d'information. 

Le tableau suivant resume les caracteristiques des principaux langages objet. Le 
cas de Smalltalk est particulier car les caracteristiques du langage peuvent etre 
etendues en intervenant au niveau des metaclasses. 





Ada 95 


C++ 


Eiffel 


Java 


Smalltalk 


Paquetage 


Oui 


Non 


Non 


Oui 


Non 


Heritage 


Simple 


Multiple 


Multiple 


Simple 


Simple 


Genericite 


Oui 


Oui 


Oui 


Non 


Non 


Typage 


Fort 


Fort 


Fort 


Fort 


Non type 


Liaison 


Dynamique 


Dynamique 


Dynamique 


Dynamique 


Dynamique 


Parallelisme 


Oui 


Non 


Non 


Oui 


Non 


Ramasse-miettes 


Non 


Non 


Oui 


Oui 


Oui 


Assertions 


Non 


Non 


Oui 


Non 


Non 


Persistance 


Non 


Non 


Non 


Non 


Non 



Figure 316 : Tableau recapitulatif des grandes caracteristiques des principaux langages 

objet. 



La transition vers I'objet 

La transition d'une organisation vers la technologie objet demande un temps non 
negligeable. 

Pour des developpeurs confirmes, il faut compter en moyenne : 

• 1 mois pour maitriser les constructions d'un langage objet, 

• 6 a 9 mois pour acquerir un mode de pensee objet, 

• 1 mois pour maitriser une bibliotheque de classes, 

• 6 a 9 mois pour dominer un framework. 
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II faut savoir neanmoins qu'une petite minorite de refractaires ne parviendront 
jamais a sauter le pas (entre 10 et 15 % des developpeurs). Aucun critere simple 
ne permet a priori de les identifier. 

Pour faciliter la transition, il est fortement conseille : 

• de faire appel a des competences externes, 

• de lancer un projet pilote, 

• de mettre en place un plan de formation sous une forme qui combine theorie et 
pratique, 

• d' avoir recours a des specialistes du transfert de technologie qui 
accompagneront le projet, 

• de former tout le monde, les developpeurs mais aussi les groupes de test, les 
equipes d'assurance qualite et l'encadrement. 

La transition vers l'objet est couteuse. II est sage de prevoir un surcout de 10 a 
20 % pour le premier projet objet du fait de l'apprentissage des differentes 
techniques par l'equipe de developpement et de 1' experimentation de la gestion 
du cycle iteratif par l'encadrement. Les benefices de la transition ne seront 
recoltes qu'a partir du deuxieme ou troisieme projet, qui devrait demander de 20 a 
30 % de ressources en moins. 



Vers une methode de developpement 



Un processus de developpement de logiciel a pour objectif la formalisation des 
activites liees a l'elaboration des systemes informatiques. La formalisation d'un 
processus de developpement vise a doter les entreprises d'un ensemble de 
mecanismes qui, lorsqu'ils sont appliques systematiquement, permettent 
d'obtenir de maniere repetitive et fiable des systemes logiciels de qualite 
constante. Par nature, la description du processus reste generate car il n'est pas 
possible de definir autoritairement un standard unique, adapte a toutes les 
personnes, tous les types d' applications et toutes les cultures. II convient plutot 
de parler de cadre configurable, eventuellement raffine de maniere consensuelle 
par la pratique et la mise en ceuvre de produits largement adoptes par la 
communaute des utilisateurs. 

Une methode de developpement comprend : 

• des elements de modelisation qui sont les briques conceptuelles de base, 

• une notation dont l'objectif est d'assurer le rendu visuel des elements de 
modelisation, 

• un processus qui decrit les etapes a suivre lors du developpement du 
systeme, 
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• du savoir-faire, plus ou moins formalise. 

Watts S. Humphrey a propose cinq niveaux de maturite 25 des processus de 
developpement de logiciel : 

• initial : le developpement n'est pas formalise, l'equipe reagit au jour le jour et 
choisit des solutions au cas par cas de sorte que le succes depend fortement 
des personnes impliquees dans le projet, 

• reproductible : l'organisation est capable d'etablir des plans raisonnables en 
termes de budget et de verifier l'etat d'avancement du projet par rapport a ces 
plans, 

• defini : le processus de developpement est bien defini, connu et compris par 
tous les intervenants du projet, 

• encadre : les performances du processus de developpement sont mesurables 
objectivement, 

• optimisant : les donnees de controle des performances du processus 
permettent 1' amelioration du processus. 

A partir de ce modele, le SEI {Software Engineering Institute) de l'universite de 
Carnegie Mellon a developpe une procedure devaluation des processus de 
developpement connue sous l'abreviation CMM {Capability Maturity Model). 

Le diagramme suivant represente les cinq niveaux de maturite des processus. 




Initial 



Figure 317 : Representation des cinq niveaux de maturite des processus de developpement 

selon Watts S. Humphrey. 

La segmentation de la modelisation permet de gerer la complexite en reduisant la 
portee de 1' etude a une partie, un sous-ensemble ou un point de vue. De cette 
maniere, lorsque le tout est trop complexe pour etre compris d'un seul coup, la 
comprehension globale peut se degager par la perception parallele de plusieurs 
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vues disjointes, mais concourantes. Le choix des points de vue, c'est-a-dire de ce 
qui est modelise, influence fortement la maniere d'approcher le probleme, et done 
la forme des solutions qui retenues. II n'existe pas de modele universel et les 
niveaux de detail, de precision ou de fidelite peuvent varier. Les meilleurs modeles 
sont en prise directe sur la realite. 

UML est un langage pour la representation des modeles objet, mais le processus 
d'elaboration de ces modeles n'est pas decrit par UML. Les auteurs d'UML 
insistent neanmoins sur les caracteristiques suivantes, qui leur semblent 
essentielles pour un processus de developpement : 

• pilote par les cas d'utilisation : toutes les activites, de la specification de ce 
qui doit etre fait jusqu'a la maintenance, sont guidees par les cas d'utilisation. 

• centre sur V architecture . Des le depart, le projet place la determination des 
traits de 1' architecture en ligne de mire. L' architecture est concue pour 
satisfaire les besoins exprimes dans les cas d'utilisation, mais aussi pour 
prendre en compte les evolutions et les contraintes de realisation. 
L' architecture doit etre simple et se comprendre de maniere intuitive ; elle est 
concue avec et pour la reutilisation. 

• iteratif et incremental : l'ensemble du travail est divise en petites iterations, 
definies a partir du degre d'importance des cas d'utilisation et de l'etude des 
risques. Le developpement precede par des iterations qui conduisent a des 
livraisons incrementales du systeme. Les iterations peuvent etre conduites en 
par allele. 

Le diagramme suivant represente la forme generale du processus de 
developpement preconise par les auteurs d'UML. 



Architecture 



Cas d'utilisation 




«Pilotes3ar» 



«Centie sur» 




Iteratif et incremental 
W 



«Derou)ement» 



Processus Generique 




Groupe A 



Entreprise B 



Figure 318 : Le processus de developpement preconise par les auteurs d'UML est pilote par 
les cas d'utilisation, centre sur V architecture et deroule de maniere iterative et incrementale. 
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Les cas d'utilisation 

Les cas d'utilisation (use cases) viennent en complement de l'approche objet et 
forment la base du processus de developpement. Dans ce contexte, les cas 
d'utilisation doivent etre vus comme un fil rouge ; ce fil balise les differentes 
activites du developpement de l'expression des besoins d'un utilisateur vers la 
realisation informatique qui satisfait ces besoins. 



Figure 319 : Les cas d'utilisation balisent les differentes activites et etapes du processus. 

Les besoins sont d'abord segmentes par rapport aux differents types 
d'utilisateurs (les acteurs) et decrits par des cas d'utilisation exprimes dans le 
langage des acteurs. A ce stade, les cas d'utilisation aident l'utilisateur a articuler 
ses besoins : il decrit les services qu'il attend du systeme sous la forme 
d' interactions entre l'acteur et le systeme. L'analyse des besoins est 
principalement exprimee par un modele des cas d'utilisation. 

Le processus continue par une demarche d'analyse objet. Les objets qui 
appartiennent fondamentalement au domaine de 1' application sont identifies, puis 
decrits de maniere generale par leurs classes. Chaque cas d'utilisation est ensuite 
realise par une collaboration entre les objets trouves precedemment. La 
decomposition n'est pas fonctionnelle : la collaboration qui realise un cas 
d'utilisation n'est qu'un cas particulier des collaborations potentielles generees 
par la structure des classes. 

Le passage de l'analyse a la conception est marque par 1' introduction de 
considerations de realisation dans les modeles. L'analyse decrit le quoi d'un 
systeme alors que la conception s'interesse au comment. Les cas d'utilisation 
continuent de baliser la conception puisqu'ils specifient ce que les mecanismes 
doivent faire. 

Les cas d'utilisation decrivent les tests fonctionnels. 
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Figure 320 : Les cas d'utilisation coordonnent et balisent les differents modeles. 

Pour autant, les cas d'utilisation ne donnent pas la forme du systeme. Dans une 
approche objet, la forme (1' architecture) du logiciel ne reflete pas la forme des cas 
d'utilisation. 

Architecture logicielle 

Le developpement d'un logiciel peut etre vu comme la traversee d'un ocean en 
bateau. Le jour de depart est connu, le jour d'arrivee Test moins, et en cours de 
route, il faudra affronter des tempetes et reparer des avaries. La conception de 
l'architecture d'un logiciel a pour objet de donner a un effort de developpement 
les moyens de parvenir a bon port. 

L'architecture logicielle s'interesse a la forme globale d'une application : cette 
forme emerge de la conception au-dela des structures de donnees ou des 
algorithmes 26 . L'architecture logicielle se preoccupe d'integrite, d'uniformite, de 
simplicite et d'esthetisme. Elle est presque a contre-courant d'une discipline (le 
developpement de logiciel) que rien ne predispose aux vertus evoquees plus 
haut, du fait principalement de l'immaterialite du logiciel et de 1' absence de 
contraintes physiques. 

La mise en place d'une architecture adaptee est la cle de voute du succes d'un 
developpement. II importe de la stabiliser le plus tot possible. II n'existe pas 
d' architecture universelle, adaptee a tous les types d' applications. En revanche, il 
existe des architectures reutilisables, dans les limites d'un domaine particulier. 



Garland D., Shaw, M. 1993, An Introduction to Software Architecture. 
Advances in Software Engineering and Knowledge Engineering, Vol. 1, 
Singapore, World Scientific Publishing Co., pp. 1-39 
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Perry et Wolf 27 definissent l'architecture des logiciels par la formule suivante : 



Architecture logicielle = Elements + Formes + 
Motivations 



Dans le contexte de la demarche objet, les elements sont les objets et les classes, 
les formes sont des regroupements de classes et d' objets (les patterns), et les 
motivations expliquent pourquoi tel ou tel regroupement est plus adapte qu'un 
autre dans un contexte donne. 

L'architecture offre une vision globale de 1' application ; elle decrit les choix 
strategiques qui determinent les qualites du logiciel, comme la fiabilite, 
l'adaptabilite ou la garantie des performances, tout en menageant des espaces 
pour les decisions tactiques prises en cours de developpement 28 . 



Architecture 




Figure 321 : L'architecture reflete les choix strategiques generaux et menage des espaces 
pour les decisions tactiques ponctuelles. 

Les bonnes architectures se caracterisent par : 

• la simplicite, 

• 1' elegance, 

• 1' intelligibility, 

• des niveaux d' abstraction bien definis, 



Perry D. E.and Wolf A. L. Oct. 1992, Foundations for the Study of Software 
Architecture. ACM Software Eng. Notes, pp. 40-52. 

28 Pour prendre une image gastronomique, le developpement consiste a 
transformer un morceau de gruyere en un morceau de comte, par remplissage des 
trous ! 
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• une separation claire entre l'interface et 1' implementation de chaque niveau. 
La vision de l'architecte 

II n'existe pas une seule maniere de considerer un systeme. De multiples points de 
vue sont requis. Par ailleurs, pour satisfaire les multiples intervenants chaque 
type de diagramme ne donne qu'une image partielle d'un systeme. 

Tous les projets objet couronnes de succes se caracterisent par la presence d'une 
forte vision de 1' architecture . Cette vision peut etre decrite a partir de plusieurs 
vues complementaires, inspirees de celles decrites par Philippe Kruchten 29 , dans 
son modele dit des 4 + 1 vues. 



Figure 322 : Representation du modele d' architecture de Philippe Kruchten. 

Ce modele d' architecture est bien adapte a la representation des contraintes 
variees que l'architecte doit prendre en consideration. 

La vue logique 

La vue logique decrit les aspects statiques et dynamiques d'un systeme en 
termes de classes et d'objets et se concentre sur 1' abstraction, l'encapsulation et 
l'uniformite. Le systeme est decompose dans un jeu d'abstractions-cles, 
originellement issues du domaine du probleme. Au-dela de la satisfaction des 
besoins fonctionnels de l'utilisateur, la vue logique permet d'identifier et de 
generaliser les elements et les mecanismes qui constituent les differentes parties 
du systeme. 

La vue logique met en jeu les elements de modelisation suivants : 

• les objets, 

• les classes, 

• les collaborations, 

• les interactions, 



Kruchten P. Nov. 95, The 4+1 View Model of Architecture. IEEE Software. 
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• les categories (paquetages stereotypes). 
La vue de realisation 

La vue de realisation se preoccupe de l'organisation des modules dans 
l'environnement de developpement. Elle montre l'allocation des classes dans les 
modules, et l'allocation des modules dans les sous-systemes. Les sous-systemes 
sont eux-memes organises en niveaux hierarchiques aux interfaces bien definies. 

La vue de realisation traite des elements de modelisation suivants : 

• les modules, 

• les sous-programmes, 

• les taches (en tant qu'unites de programme, comme en Ada), 

• les sous-systemes (paquetages stereotypes). 

La vue des processus 

La vue des processus represente la decomposition en flots d'execution 
(processus, threads, taches...), la synchronisation entre flots et l'allocation des 
objets et des classes au sein des differents flots. La vue des processus se 
preoccupe egalement de la disponibilite du systeme, de la fiabilite des 
applications et des performances. 

La vue des processus prend toute son importance dans les environnements 
multitaches. 

La vue des processus manipule les elements de modelisation suivants : 

• les taches, les threads, les processus, 

• les interactions. 

La vue de deploiement 

La vue de deploiement decrit les differentes ressources materielles et 
l'implantation du logiciel dans ces ressources. 

La vue de deploiement traite les points suivants : 

• les temps de reponse et les performances du systeme, 

• la bande passante des chemins de communication et les capacites, 

• les contraintes geographiques (disposition physique des processeurs), 

• les besoins en puissance de calcul distribute, 

• les surcharges et l'equilibrage des charges dans un systeme distribue, 

• la tolerance aux fautes et aux pannes. 
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La vue de deploiement prend toute son importance lorsque le systeme est 
distribue. 

La vue de deploiement se concentre sur les elements de modelisation suivants : 

• les nceuds, 

• les modules, 

• les programmes principaux. 

La vue des cas d'utilisation 

Les cas d'utilisation forment la colle qui unifie les quatre vues precedentes. Les 
cas d'utilisation motivent et justifient les choix d' architecture. lis permettent 
d'identifier les interfaces critiques, ils forcent les concepteurs a se concentrer sur 
les problemes concrets, ils demontrent et valident les autres vues d'architecture. 

La vue des cas d'utilisation rend compte des elements de modelisation suivants : 

• les acteurs, 

• les cas d'utilisation, 

• les classes, 

• les collaborations. 

Organisation des modeles 

Les cinq vues decrites plus haut, associees au concept de paquetage, permettent 
la structuration hierarchique d'un modele. Un modele decrit par UML prend la 
forme de l'arborescence representee dans le diagramme de classes suivant : 
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Figure 323 : Extrait du metamodele. Organisation hierarchique des modeles selon plusieurs 

vues. 

Les paquetages sont a la fois des elements de modelisation et des elements de 
structuration des modeles. L' arborescence des paquetages organise les modeles, 
comme les repertoires organisent les systemes de fichiers. 

Le diagramme d'objets suivant donne un exemple d' organisation d'un modele, 
structure selon les cinq vues d' architecture presentees plus haut : 
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Figure 324 : Exemple de modele structure selon cinq vues d' architecture. 
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Documentation de l'architecture 

L' architecture est decrite dans un document d' architecture qui comprend : 

• une description textuelle des traits de l'architecture (les vues) et les besoins- 
cles du systeme, 

• les compromis retenus et les alternatives explorees, 

• une representation de haut niveau de la vue logique (entre 5 et 50 classes- 
cles), 

• des scenarios specifiques a l'architecture, 

• la description des mecanismes-cles. 

Articulation des differents diagrammes 

Les elements de modelisation sont accessibles a l'utilisateur par 1' intermediate de 
projections graphiques (les elements de visualisation) representees dans les 
neufs types de diagrammes suivants : 



Diagramme 



Composants 



Deploiement 



Classes 



Cas d'utilisation 



1 



Etats-Transitions 











Sequence 




Activite 









Objets 



Collaboration 



Figure 325 : Representation des neuf types de diagrammes definis par UML. 

Ces diagrammes forment la base des vues d' architecture decrites plus haut. II 
importe de bien conceptualiser les liens entre les differents elements de 
modelisation et leurs representations associees afin de documenter un systeme 
avec clarte et efficacite. 

Un modele est une construction semantique, organisee sous la forme d'un reseau. 
Ce reseau peut se parcourir en suivant les regies generales decrites dans le 
metamodele d'UML. 

Les differents diagrammes peuvent etre vus comme des chemins graphiques 
parcourant les modeles. Les paragraphes suivants proposent un exemple de 
cheminement, depuis l'enonce des besoins jusqu'au deploiement dans le materiel. 
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Expression des besoins 

L'expression des besoins d'une categorie d'utilisateur est decrite sous une forme 
fonctionnelle dans les cas d'utilisation. Les cas d'utilisation sont exprimes en 
langage naturel, dans les termes de l'utilisateur. 



Acteur 



Cas d'utilisation 



Besoin 



Figure 326 : Les besoms des utilisateurs sont exprimes, acteur par acteur, sous la forme de 

cas d' utilisation. 



Transition vers l'objet 

La transition vers l'objet est operee par l'analyste. II realise le comportement 
decrit dans le cas d'utilisation au moyen d'une collaboration entre des objets, 
initialement issus du domaine de 1' application. Le contexte d'une collaboration est 
represente dans un diagramme d'objets. 
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Figure 327 : La transition vers l'objet est operee en realisant un cas d'utilisation par une 
collaboration entre objets du domaine. 



Expression du comportement 

Le comportement d'une collaboration ou d'une classe peut se representer sous la 
forme d'une interaction ou d'un automate. Les interactions sont visualisees du 
point de vue temporel, par des diagrammes de sequence et du point de vue 
spatial, par des diagrammes de collaboration. Les automates sont visualises du 
point de vue des etats et des transitions, par des diagrammes d'etats-transitions 
et du point de vue des activites, par des diagrammes d'activites. 
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Figure 328 : UML propose 5 types de diagramm.es pour la representation du comportement. 



Representation de la structure 

Chaque objet est instance d'une classe. Les classes du domaine decrivent de 
maniere generale les objets metiers. Les objets sont representes dans les 
diagrammes d'objets, dans les diagrammes de collaboration et dans les 
diagrammes de sequence. Les classes sont representees dans les diagrammes de 
classes. 
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Figure 329 : Chaque objet est instance d'une classe. 
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Realisation des objets et des classes 

Le code qui realise les classes, les objets et les interactions entre ces objets est 
stocke dans des composants qui constituent les briques de la structure physique 
des systemes. Les composants regroupent les modules, les sous-programmes, les 
taches (au sens des unites de programmes Ada) et les programmes principaux. 

Les modules contiennent le code qui correspond aux classes et aux objets, les 
programmes principaux contiennent le code qui correspond aux points d'entree 
dans la realisation des interactions. Un module peut contenir plusieurs classes et 
plusieurs objets, mais par defaut, il n'y a qu'une seule classe par module ; le nom 
de la classe est utilise pour construire le nom du module dans l'espace de 
developpement. 

Un diagramme de composants montre les dependances de compilation entre les 
differents composants d'une application. 
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Figure 330 : Le code qui correspond aux objets et aux classes est stocke dans des modules. 

Deploiement du code executable 

Un programme principal est une sorte de composant qui contient un code 
executable correspondant a une ou plusieurs interactions. Tres sou vent, un 
programme principal ne correspond qu'a une seule interaction. Un programme 
principal est deploye sur des noeuds, au sein de processus qui l'executent. 

Les diagrammes de deploiement montrent les differentes sortes de processeurs et 
de dispositifs qui composent l'environnement d'execution du systeme ; ils 
montrent aussi la configuration de composants, de processus et d'objets qui 
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s'executent dans cet environnement. Si necessaire, la migration des objets et des 
processus est representee au moyen d'une relation de dependance stereotypee. 
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Figure 331 : Un programme principal est une sorte de composant qui contient un code 
executable correspondant a une ou plusieurs interactions. 



Organisation des modeles et des vues 

Les paquetages organisent les vues et les modeles en encapsulant les autres 
elements de modelisation dans une decomposition hierarchique, analogue a la 
structuration d'un systeme de fichiers par des repertoires : 

• dans la vue logique, les paquetages contiennent des objets, des classes, 
d' autres paquetages, et les diagrammes qui visualisent ces elements, 

• dans la vue de realisation, les paquetages contiennent des composants et 
d' autres paquetages et les diagrammes correspondants. 

Les paquetages peuvent etre specialises sous la forme de categories et de sous- 
systemes, pour distinguer respectivement les paquetages de la vue logique et les 
paquetages de la vue de realisation. 
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Figure 332 : Exemple de specialisation des paquetages pour distinguer les concepts 
d 'organisation de la vue logique, de ceux de la vue de realisation. 

En regie generale, il y a correspondance directe entre une categorie et un sous- 
systeme. Les hierarchies de categories et de sous-systemes peuvent differer, 
entre autres pour : 
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• regrouper des objets qui ont une forte interaction, 

• realiser des fonctionnalites de bas niveau, non representees en analyse, 

• repartir le travail dans l'equipe de developpement. 

Granularite des elements de modelisation 

Les elements de modelisation d'UML suivent une dichotomie telle que pour un 
type de concept donne, il existe toujours un element de modelisation a granularite 
fine et un element de modelisation a granularite plus elevee. 

Le diagramme suivant illustre les correspondances entre les elements a granularite 
forte. 
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Figure 333 : Representation des correspondances entre les elements a granularite forte. 

Les elements a plus faible granularite sont egalement en correspondance. 
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Figure 334 : Representation des correspondances entre les elements a granularite fine. 

Vue par vue, les elements a forte granularite sont des agregats d'elements a 
granularite plus fine. UML permet de construire des modeles empreints de cette 
decomposition hierarchique, et favorise ainsi la navigation entre les differents 
points de vue et entre les niveaux de details de ces points de vue. 
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Figure 335 : Correspondance entre les elements de modelisation au sein d'une representation 
hierarchique materialisee par les agregations. 



Cette dichotomie entre elements peut etre representee sous la forme d'un 
empilement pyramidal des elements de modelisation d'UML ; il montre que tous 
les elements sont visibles simultanement en cas de besoin, mais que la vision 
peut egalement se limiter a un niveau d' abstraction donne. 
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Figure 336 : Representation pyramidale des elements de modelisation d'UML. 

La figure precedente fournit une vue du dessus de cet empilement. Les elements 
de meme niveau hierarchique dans la pyramide sont en correspondance vue par 
vue. La base de la pyramide regroupe les elements a forte granularite, l'etage 
intermediaire contient les elements a fine granularite et le sommet est constitue 
des cas d'utilisation. Ces derniers se realisent par des collaborations construites a 
partir des elements des niveaux inferieurs. 

Grace a ces correspondances entre elements de modelisation, UML facilite la 
navigation entre les points de vue generaux et les points de vue detailles, comme 
le decrit Grady Booch, pour qui la forme generale influence les formes detaillees et 
reciproquement. II qualifie sa demarche de Round Trip Gestalt 30 . 

Recapitulatif des elements et des vues 

Le tableau suivant resume l'utilisation courante des elements dans les differents 
diagrammes dans le but de representer les differents points de vue. Cette 
representation n'est pas limitative ; l'utilisateur est libre de representer les 
elements qu'il trouve pertinents dans les diagrammes qui lui conviennent. 



Booch G. 1994, Object-Oriented Analysis and Design, with Applications. 
Benjamin Cummings. 
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Figure 337 : Tableau recapitulatif de I 'utilisation des elements dans les differents types de 
diagrammes dans le but de representer les differents points de vue. 



Micro-architecture 

Le terme anglais pattern, en franfais forme, micro-architecture, ou scheme, 
designe des combinaisons recurrentes d'objets et de classes. Elle se retrouvent 
frequemment dans les conceptions objet et peuvent etre qualifiees de savoir-faire 
objet. Le principal interet des patterns est de permettre la manipulation de 



232 - Modelisation objet avec UML 



concepts d' architecture plus elabores que les objets et classes. lis augmentent la 
puissance d'expression des langages de modelisation. Cette demarche evite 
egalement de trop s'attarder sur des objets lies aux particularites du domaine de 
1' application, et ainsi de rechercher des conceptions de plus haut niveau, 
eventuellement moins performantes, mais plus flexibles et plus extensibles. Dans 
une certaine mesure, un pattern est pour les objets, l'equivalent du sous- 
programme pour les instructions, ou encore des circuits integres pour les 
transistors. Le pattern est 1' unite de reutilisation de conception objet. 

Le concept de pattern 31 a ete decrit par Christopher Alexander 32 . Cet architecte 
desirait formaliser les grands traits de 1' architecture afin de faciliter la construction 
des bailments. Cette idee de formalisation des elements d' architecture, ou encore 
des formes d' architecture (d'ou le terme de pattern), peut tout a fait etre 
transposed dans le domaine du logiciel, afin de definir des formes logicielles 
reutilisables d' applications en applications. 

UML represente les patterns par les collaborations. Une collaboration regroupe 
un contexte d'objets et une interaction entre ces objets. Une collaboration 
convient done pour la representation des patterns de structure, comme des 
patterns de comportement. Les collaborations sont representees par des ellipses 
pointillees, connectees aux objets qui y participent. 

Le diagramme suivant represente un pattern de chaine de responsabilite. 



" Alexander C, Ishikawa S., Silverstein M., Jacobson M., Fiskdahl-King I., Angel 
S. 1977, A Pattern Language. Oxford University Press, New York. 

32 « Each pattern describes a problem which occurs over and over again in our 
environment, and then describes the core of the solution to that problem, in 
such a way that you can use this solution a million times over, without ever 
doing it the same way twice. » Christopher Alexander 
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Figure 338 : Representation d'un pattern chaine de responsabilite par une 

collaboration. 



II existe egalement des patterns d'analyse, construits a partir d'objets metiers, et 
dedies specifiquement a des logiciels deployes dans un domaine donne. 

Description des patterns 

La description 33 precise des patterns est essentielle pour permettre leur mise en 
oeuvre. Au minimum, un pattern est decrit par : 

• un nom pour augmenter le niveau d' abstraction du langage de modelisation, 

• un probleme avec son contexte et des pre- et post-conditions, 

• une solution abstraite independante des langages de programmation, 

• des consequences en termes de flexibilite, d'extensibilite et de portabilite. 

Monies 

Les patterns sont des constructions caracteristiques totalement independantes 
des langages de realisation. Les patterns formalisent des choix d' architecture qui 
peuvent etre mis en ceuvre de maniere uniforme, quel que soit l'environnement de 
realisation. Parallelement a ces formes independantes, il existe des constructions 
recurrentes specifiques a un langage de programmation donne. Ces formes 
particulieres, appelees idiomes, regroupent des constructions syntaxiques 
existantes. Les idiomes permettent de former de nouvelles constructions et ne 
sont generalement pas transposables tels quels d'un langage a 1' autre. 



~ Gamma E., Helm R., Johnson R., Vlissides J. 1995, Elements of Reusable Object- 
Oriented Software. Addison- Wesley. 
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Les idiomes appartiennent au florilege de trues et astuces qui accompagnent un 
style de programmation, considere comme elegant dans un langage donne. Selon 
la puissance d'expression des langages, une technique donnee peut etre un 
idiome dans un langage et une construction syntaxique dans un autre. 

La copie d'une chaine de caracteres en C++ peut se realiser de la maniere 
suivante : 

j; While (*destination++ = *source++) ; 

En Ada, les noms peuvent etre prefixes : 
j| Standard. Mailbox. Open ; 

En C++, beaucoup de techniques de programmation - comme la gestion de la 
memoire, les entrees-sorties ou 1' initialisation - relevent des idiomes. Ces idiomes 
sont decrits dans des ouvrages 34 qui se presentent comme des manuels de 
programmation avancee. A l'usage, C++ se revele etre un langage assez difficile a 
utiliser, du fait de la necessite de maitriser un grand nombre d'idiomes pour 
programmer efficacement. 

Macro-architecture 

La representation des grands systemes fait appel a de nombreuses classes. Du 
fait de la complexite des modeles - dont le contenu depasse rapidement les 
limites 35 de comprehension de l'etre humain - il est impossible de distinguer les 
traits de 1' architecture dans les entrelacs de classes et de relations. L' architecture 
generale d'une application ne peut pas se representer a partir d'elements a fine 
granularite ; il faut introduire des concepts structurants plus larges pour faire 
emerger la macrostructure et pour faciliter la comprehension des modeles. 

Les patterns decrivent de petites formes recurrentes, utilisables au jour le jour 
pour resoudre des problemes ponctuels. Ces patterns n'expriment pas la forme 
generale d'une application. C'est pourquoi des representations plus larges 
regroupent les patterns au sein de frameworks, veritables infrastructures 
reutilisables, dediees a la realisation d' applications ciblees. Ces frameworks 



~ Meyers S. 1991, Effective C++, 50 Specific Ways to Improve Your Programs 
and Designs. Addison Wesley. 

35 Miller G. March 1956, The Magical Number Seven, Plus or Minus Two: Some 
Limits on Our Capacity for Processing Information. The Psychological Review 
V. 63 (2). 
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peuvent etre representes au moyen des trois concepts structurants proposes par 
UML : les cas d'utilisation, les paquetages et les collaborations. Ces concepts 
expriment respectivement, le comportement vu de l'exterieur, la macrostructure 
statique et les patterns. 

La macro-architecture se represente au moyen de categories (paquetages 
stereotypes pour insister sur leur fonction architecturale). Les categories 
encapsulent les classes et les objets couples logiquement au sein d'elements plus 
larges. lis permettent ainsi de construire des niveaux hierarchiques. lis 
segmentent une application en couches d'abstraction croissante. Chaque niveau 
possede des interfaces bien definies. Un niveau de rang donne ne depend que 
des niveaux de rang inferieur. La forme general e d'une application se represente 
par des diagrammes de categories, en fait des diagrammes de classes qui ne 
contiennent que des categories. Les differentes categories sont reliees entre elles 
par des relations de dependances stereotypees pour representer les imports entre 
categories. 



1 
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«Categorie» 
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Figure 339 : Exemple de representation des categories et des imports entre categories. 

Le diagramme de categories suivant represente un exemple de macrostructure. Le 
stereotype «Framework>> a ete defini afin de designer des ensembles de 
classes stabilisees, reutilisables d' applications en applications. L' application est 
composee de quatre niveaux d'abstraction. Le niveau le plus bas encapsule les 
specificites du systeme d'exploitation. Le deuxieme niveau offre des services de 
communication et de persistance. Le troisieme niveau comprend un framework de 
controle-commande et deux categories d'objets metiers : les machines-outils et les 
gammes d'usinage. Le dernier niveau contient un framework d'objets graphiques 
reutilisables et une categorie IHM qui contient des objets miroirs des objets 
metiers. Les trois categories de plus bas niveau pourraient tres certainement etre 
transformees en un framework. 
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Figure 340 : Exemple de diagramme de categories pour la representation de la structure 
generate d'une application. 



La place du logiciel ou le choc des cultures 

Selon la part de materiel specifique construit par l'entreprise, une distinction peut 
etre operee entre l'architecte du systeme et l'architecte du logiciel. L'architecte du 
systeme est responsable pour l'ensemble du systeme, le materiel, le logiciel et 
l'utilisation. L'architecte du logiciel ne se consacre qu'a la partie logicielle. 

Cette distinction est logique, mais peut se reveler malheureuse lorsque 
l'architecte principal ne connait pas assez le logiciel. Un bon architecte doit 
connaitre a la fois le domaine de 1' application et les differentes techniques 
employees dans la realisation, dont le logiciel. 

Dans les quinze dernieres annees, de nombreuses entreprises se sont trouvees 
confrontees a une profonde mutation de leur activite du fait de l'introduction de 
l'informatique dans leurs produits. Souvent, le choix de l'architecte depend plus 
de sa connaissance du domaine que de sa connaissance de l'informatique. Cette 
situation est particulierement sensible dans les entreprises qui ont bati une 
culture electromecanique, puis mute vers l'electronique ; elles percoivent souvent 
l'informatique comme un accessoire de plus et non comme le lien integrateur 
qu'elle devrait etre. 
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Les diagrammes suivants decrivent la situation. A l'origine, la part de materiel 
etait predominante ; le metier de l'entreprise etait essentiellement exprime au 
travers de ce materiel. 

1^^^^^ Ma:6riel 

Figure 341 : A l'origine, le savoir-faire de l'entreprise est exprime par du materiel. 

Petit a petit, des elements logiciels ont ete rajoutes pour controler, commander ou 
reguler. Ces premiers programmes ont d'abord ete developpes en assembleur ; ils 
restent tres proches du materiel. 

Cette topologie d'application est la consequence d'un manque de vision globale. 
Elle se traduit par une absence totale d'integration entre les composants logiciels 
et par une duplication de l'effort, allant parfois jusqu'a des redondances 
materielles. Dans le domaine de 1' automobile, les systemes distincts d'anti- 
patinage et d'anti-blocage des roues illustrent bien ce phenomene. 




Figure 342 : Des elements logiciels sont rajoutes dans le systeme, sans concertation. 

Le choc culturel a lieu lorsque la tendance s' inverse au profit du logiciel, parfois 
par necessite economique. II est licite de parler d' architecture logicielle a partir du 
moment ou une demarche raisonnee, unificatrice et integrante regroupe le logiciel 
et le materiel au sein d'un cadre cooperant. 
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Figure 343 : Le choc culturel correspond a V inversion du cadre integrant. 



Lorsque la mutation est operee totalement, le savoir-faire de l'entreprise est 
completement transfere dans le logiciel. Le materiel specifique n'existe plus, ou 
alors est integre dans l'architecture generale du logiciel. Cette mutation a deja ete 
vecue par des entreprises de CAO ou d'imagerie medicale. 



Figure 344 : Apres mutation, le savoir-faire de l'entreprise est exprime dans du logiciel. 

L'informatique est un catalyseur. L'informatique s'est lovee dans les materiels, 
tant et tant que l'informatique a cesse d'etre secondaire pour devenir principale. 
Ceci ne se fait pas toujours sans douleur du fait du profond choc culturel entraine 
par cette mutation des metiers. Les personnes de l'entreprise qui detenaient 
traditionnellement le savoir du metier se sentent depossedees ; elles reagissent, 
inconsciemment, en freinant des deux pieds et en essayant de confiner 
l'informatique dans des taches accessoires. Ce probleme est difficile a gerer car 
souvent les personnes qui freinent le plus fort ont suffisamment de pouvoir de 
decision pour imposer leur vision. 

Cette attitude conservatrice engendre un desequilibre dans l'architecture au profit 
du materiel : le logiciel est alors sous-employe. Un architecte qui ne possede pas 
de vision logicielle concoit des systemes dans lesquels le logiciel est mal integre 
avec le materiel, au lieu de concevoir des systemes dans lesquels le materiel est 
bien integre dans le logiciel. Au-dela des habitudes, le probleme est lie a une 
mauvaise analyse. Les solutions proposees ne sont pas assez innovantes et se 
contentent souvent d'informatiser l'existant. 

Cette situation n'est pas reservee a l'informatique technique et se manifeste 
egalement dans le monde des systemes d' information des entreprises. Les 
processus en place dans l'entreprise sont l'equivalent des elements materiels 
specifiques decrits precedemment ; le savoir-faire de l'entreprise est traduit dans 
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ces processus. L'approche conservatrice attend - et admet - de 1' informatique 
l'automatisation de certaines taches, mais seulement au sein de processus deja en 
place. 




Processus 




Processus 



Figure 345 : Informatization limitee dans le cadre d'un processus en place dans Ventreprise. 

La rupture est consommee lorsque l'informatisation depasse le cadre d'un 
processus donne et recherche l'integration entre plusieurs processus, par 
exemple pour echanger de l'information. Dans les faits, cela se traduit 
generalement par la detection d'incoherences, de pertes de temps, de 
mouvements inutiles. Le choc culturel resultant est souvent plus intense que 
dans le monde technique. Les consequences d'une remise a plat des processus 
d'une entreprise touchent plus directement les personnes et leur emploi. 




Figure 346 : Integration des processus d'une entreprise dans un cadre informatique global. 



Cycle de vie iteratifet incremental 

Le cycle de vie iteratif repose sur une idee tres simple : lorsqu'un systeme est trop 
complexe pour etre compris, concu ou realise du premier coup, voire les trois a la 
fois, il vaut mieux le realiser en plusieurs fois par evolutions. Dans la nature, les 
systemes complexes qui fonctionnent sont toujours des evolutions de systemes 
plus simples 36 . 

La mise en oeuvre de cette idee n'est pas aussi simple que cela dans le monde de 
1'informatique : le logiciel ne se prete pas spontanement a revolution. Au 



Gall, J. 1986, Systematics : How Systems Really Work and How They Fail. 2' 
ed. Ann Arbor, MI : The General Systematics Press. 
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contraire, le logiciel se revele sou vent extremement fragile en face d'un 
changement ou d'une modification. Ceci est directement lie a la forme interne des 
programmes et au couplage qui existe entre les differents constituants. L'effet 
d'une modification locale peut se propager dans l'ensemble de l'application et, a 
la limite, le basculement d'un seul bit suffit pour completement faire s'ecrouler 
une application qui fonctionnait correctement auparavant. 

Avant de parler de developpement par evolution, il faut s'attacher a rendre les 
logiciels plus stables et moins enclins a l'effondrement face a revolution. Le 
genie logiciel nous apprend que pour rendre un programme plus robuste, il faut 
segmenterl'espace des etats possibles, reduire le couplage au moyen de niveaux 
d' abstraction et separer les specifications des realisations. 

L'approche objet est batie autour de concepts comme l'encapsulation et la 
modularite qui encouragent un style de programmation defensif : par nature, les 
programmes objet presentent une resistance plus grande face aux changements et 
aux surprises. L'approche objet, de ce point de vue, favorise le developpement de 
programmes selon une demarche iterative. 

II faut etre bien conscient que l'approche objet n'est pas necessaire pour mettre 
en oeuvre un developpement iteratif ; elle n'entraine et ne requiert aucun 
developpement iteratif, mais simplement les facilite. 

En resume, l'approche objet nous fournit un cadre confortable pour developper 
par evolution, de maniere iterative. 

Cycle de vie lineaire 

L'expression cycle de vie lineaire designe une demarche de developpement de 
logiciels, basee sur une succession d'etapes, depuis le cahier des charges jusqu'a 
la realisation. 

Le modele en tunnel 

Le modele de developpement en tunnel 37 est en fait une maniere imagee de 
designer 1' absence de modele de developpement. Dans les projets qui suivent la 
demarche en tunnel, il est globalement impossible de savoir ce qui se passe. Le 
developpement est en cours, les gens travaillent - souvent beaucoup - mais 
aucune information fiable n'est disponible, ni sur l'etat d'avancement du logiciel, 
ni sur la qualite des elements deja developpes. Ce genre de modele de 
developpement n'est adapte que pour les petits efforts, avec un nombre tres 
limite de participants. 



Pierre D., communication privee. 



4 - Encadrement des projets objet - 241 




Figure 347 : Modele de developpement en tunnel, le processus de developpement n' est pas 

visible. 

Le modele en cascade 

Le cycle de vie en cascade 38 , decrit par Royce des 1970, a ete largement employe 
depuis, pour la description generale des activites liees au developpement de 
logiciels. 

Le cycle de vie en cascade presente le developpement de logiciel comme une 
suite de phases qui s'enchainent dans un deroulement lineaire, depuis 1' analyse 
des besoins jusqu'a la livraison du produit au client. Chaque phase correspond a 
une activite. 

Le developpement en cascade est rythme par la generation de documents qui 
servent de support tangible pour les revues de validation du passage d'une 
phase a une autre. 

Par rapport au modele en tunnel, le modele en cascade presente l'enorme 
avantage de fournir des points de mesure concrets, sous la forme de documents ; 
il augmente ainsi la visibilite sur l'etat d'avancement du systeme en cours de 
developpement. Le diagramme suivants illustre le gain de visibilite apporte par le 
modele en cascade. 



Royce, W. W. Aout 1970, Managing the development of large software 
systems. Proceedings of IEEE WESCON. 
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Figure 348 : Le modele de developpement en cascade ouvre des points de visibilite sur le 
processus de developpement. 

Le cycle en cascade est souvent represents sous la forme d'une lettre V pour faire 
apparaitre que le developpement des tests est effectue de maniere synchrone 
avec le developpement du logiciel. Cette approche permet de tester ce qui devait 
etre fait et non ce qui a ete fait. Le diagramme suivant montre un exemple de 
modele en V, dans lequel les tests fonctionnels sont specifies lors de 1' analyse, 
les tests d'integration lors de la conception et les tests unitaires pendant la phase 
de codage. 
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Figure 349 : Exemple de modele de developpement en V. Les tests sont developpes 
parallelement au logiciel. 



Limites du modele en cascade 

Le modele en cascade repose sur une sequence de phases bien cernees. Le projet 
produit des documents evalues lors de revues censees valider le passage d'une 
phase a une autre. Toutefois, la preuve effective du bon (ou mauvais) 
fonctionnement du systeme n'est realisee que tardivement dans le cycle - lors de 
la phase d'integration - lorsqu'il est possible d'evaluer concretement le logiciel. 
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Avant cette phase d' integration, seuls des documents ont ete produits. Or, ce 
n'est pas parce qu'un document passe avec succes une etape de validation sur 
papier que le logiciel qu'il decrit donnera forcement des resultats convaincants. 

En fait, la demarche en cascade ne donne des resultats satisfaisants que lorsqu'il 
est effectivement possible d'enchainer les phases sans trop de problemes. II faut 
que l'ensemble des besoins soit parfaitement connu et le probleme completement 
compris par les analystes ; il faut aussi que la solution soit facile a determiner par 
les concepteurs et le codage reduit idealement a la generation automatique de 
code, a partir des documents de conception. 

Helas, les projets ne se presentent pas tous sous ces conditions ideales. Force 
est de constater que la part d'inconnu, et done de risques, peut etre grande dans 
certains developpements, notamment du fait : 

• de la meconnaissance des besoins par le client, 

• de 1' incomprehension des besoins par le fournisseur, 

• de l'instabilite des besoins, qui decoule des deux points precedents, 

• des choix technologiques, 

• des mouvements de personnel... 

Pour toutes ces raisons, des retours d' information entre les phases sont 
necessaires pour incorporer des corrections en amont, en fonction des 
decouvertes realisees en aval. Ces retours entre phases perturbent la vision 
lineaire donnee par le cycle de vie en cascade, comme le montre le diagramme 
suivant : 
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Figure 350 : La part d'inconnu qui caracterise les systemes complexes se traduit par des 
retours d' information entre phases pour incorporer des corrections. 



En fait, les retours entre phases ne sont que le reflet de la realite. Tant que ces 
retours restent marginaux et limites entre phases adjacentes, le modele en cascade 
conserve toute sa pertinence. Dans le cas contraire, le modele en cascade n'est 
plus vraiment adapte. II devient alors de plus en plus artificiel de considerer le 
developpement comme un enchainement lineaire. 
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Lorsqu'un modele ne represente plus une realite, il faut en changer et non essayer 
de faire coller la realite au modele 39 . 

Caracteristiques du cycle de vie iteratif 

Le cycle de vie iteratif est base sur revolution de prototypes executables, 
mesurables, et done sur 1'evaluation d'elements concrets. II s'oppose ainsi au 
cycle de vie en cascade qui repose sur l'elaboration de documents. Les livraisons 
forcent l'equipe a donner des resultats concrets regulierement, ce qui permet 
d'eviter le syndrome des 90 % finis, avec encore 90 % a faire. Le deroulement 
regulier des iterations facilite la prise en compte des problemes ; les changements 
sont incorpores dans les iterations futures, plutot que de deranger et 
d'interrompre l'effort en cours. 

Au cours du developpement, certains prototypes sont montres aux utilisateurs et 
aux clients. La demonstration des prototypes presente de nombreux avantages : 

• l'utilisateur est place devant des situations d'utilisation concretes qui lui 
permettent de mieux structurer ses desirs et de les communiquer a l'equipe de 
developpement ; 

• l'utilisateur devient partenaire du projet ; il prend sa part de responsabilite 
dans le nouveau systeme et, de fait, l'accepte plus facilement ; 

• l'equipe de developpement est plus fortement motivee du fait de la proximite 
de l'objectif ; 

• l'integration des differents composants du logiciel est realisee de maniere 
progressive, durant la construction, sans effet big bang a l'approche de la 
date de livraison ; 

• les progres se mesurent par des programmes demontrables, plutot que par des 
documents ou des estimations comme dans le cycle de vie en cascade. 
L'encadrement dispose ainsi d'elements objectifs et peut evaluer les progres 
et l'etat d'avancement avec plus de fiabilite. 

En revanche, le cycle de vie iteratif demande plus d'attention et d'implication de 
l'ensemble des acteurs du projet. II doit etre presente et compris par tous : les 
clients, les utilisateurs, les developpeurs, l'encadrement, l'assurance qualite, les 
testeurs, les documentalistes. Tous doivent organiser leur travail en 
consequence. 

Une mini-cascade 

Dans le cycle de vie iteratif, chaque iteration reproduit le cycle de vie en cascade, 
a une plus petite echelle. Les objectifs d'une iteration sont etablis en fonction de 



~ Kuhn T. S. 1970, The Structure of Scientific Revolutions, 2" edition. The 
University of Chicago Press, Chicago. 



4 - Encadrement des projets objet - 245 



revaluation des iterations precedentes. Les activites s'enchainent ensuite dans 
une mini-cascade dont la portee est limitee par les objectifs de l'iteration. 




Figure 351 : Le cycle de vie iteratif repasse plusieurs fois par les phases du cycle de vie en 

cascade. 

Les phases traditionnelles sont couvertes graduellement, iteration apres iteration. 
La nature des activites menees au sein des phases ne varie pas fondamentalement 
selon qu'il s'agit d'un developpement iteratif ou d'un developpement en cascade. 
La difference se situe plus dans la distribution de ces activites par rapport aux 
phases. 

Chaque iteration comprend les activites suivantes : 

• la planification de l'iteration est elaboree en fonction des resultats de l'etude 
derisques ; 

• Vanalyse etudie les cas d'utilisation et les scenarios a realiser dans 
l'iteration ; elle met a jour le modele d'analyse pour prendre en compte les 
nouvelles classes et associations decouvertes pendant 1' analyse de 
l'iteration ; 

• la conception se concentre sur les choix tactiques necessaires pour realiser 
les mecanismes alloues a l'iteration. Au besoin, des retouches sont apportees 
a l'architecture et le modele de conception est mis a jour. Les procedures de 
test sont definies parallelement a la conception des nouveaux mecanismes ; 

• le codage et les tests dont la charpente du code est generee automatiquement 
depuis le modele de conception. Le detail des operations est ensuite realise 
manuellement. L'integration du nouveau code avec le code existant, issu des 
iterations precedentes, est realisee graduellement pendant la construction. Les 
procedures de tests unitaires et d' integration sont appliquees au prototype. 
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• revaluation de la livraison executable : l'examen des resultats des tests sert 
de base pour 1'evaluation du prototype. Les resultats sont evalues par rapport 
aux criteres definis avant de lancer l'iteration. 

• la preparation de la livraison : le prototype est gele et l'ensemble des 
elements qui sont entres dans son developpement est place dans des 
bibliotheques controlees. Les differents documents de description et 
d'installation du prototype sont finalises. 

Dans le diagramme suivant, les activites internes se chevauchent pour montrer 
qu'au sein d'une iteration, elles n'ont pas besoin de se terminer brutalement et 
que la transition entre deux activites peut etre progressive. Le cycle iteratif se 
distingue ici du cycle en cascade qui effectue un amalgame entre phases et 
activites. 



Figure 352 : Exemple de transition progressive entre les activites d'une iteration. 

Idees fausses sur le cycle de vie iteratif 

Le monde est plein de prejuges et d'idees fausses. L'informatique n'echappe pas 
a cette tendance et, en particulier, le cycle de vie iteratif draine dans son sillage 
bon nombre de mythes, parmi lesquels : 

• Le cycle de vie iteratif encourage la bidouille. 

Le cycle de vie iteratif encourage surtout la creativite en menageant des espaces 
de liberie, sans regies trop strictes. 

• Le cycle de vie iteratif engendre des problemes. 

Le cycle de vie iteratif n' engendre pas les problemes : il revele precocement des 
problemes qui auraient ete detectes tardivement avec le cycle en cascade. Le 
cycle en cascade semble previsible : les revues d' analyse et de conception se 
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succedent dans les delais prevus. Tout va bien jusqu'a la phase d'integration ou 
mille turpitudes sont commises pour livrer quelque chose au client. Le cycle de 
vie iteratif commence mal et se termine bien, contrairement au cycle de vie en 
cascade qui commence bien et se termine mal. 

• Le cycle de vie iteratif et incremental demande de recommencer n fois 
jusqu 'a ce que le resultat soit bon. 

Le cycle de vie iteratif ne demande pas de recommencer eternellement le meme 
programme, mais d'enrichir un programme existant par l'ajout de nouvelles 
fonctionnalites. La confusion vient du fait que certaines parties doivent etre 
retouchees, precisement parce qu'elles comportaient des defauts detectes par une 
iteration. Plus tot les problemes sont detectes dans le cycle de developpement, 
moins ils sont couteux a corriger. 

• Le cycle de vie iteratif est une excuse pour ne pas planifier et gerer un projet. 

Au contraire, le cycle de vie iteratif demande plus de planification et une attention 
soutenue. La planification n'est pas faite au debut ; elle est repartie sur 
l'ensemble du developpement. II est facile de faire des plans, il est plus difficile de 
les corriger ou d'en changer. 

• Le cycle de vie iteratif ne concerne que les developpeurs. 

II est vrai que les developpeurs se sentent a l'aise avec le cycle iteratif, mais ce 
n'est pas parce que les uns sont heureux que les autres - en particulier 
l'encadrement - doivent etre malheureux. En effet, le cycle de vie iteratif leur 
fournit plus de points de mesure que le cycle en cascade et ces mesures sont plus 
fiables : elles sont connectees sur la realite de 1'evaluation d'un prototype, plutot 
que sur la virtualite de la lecture d'une documentation. 

• Le cycle de vie iteratif encourage a rajouter toujours de nouveaux besoins, 
sans fin. 

Voila une idee fausse dont il faut absolument se defaire. L' analyse iterative ne 
consiste pas a rajouter toujours et encore de nouveaux besoins ; elle permet de se 
concentrer d'abord sur les besoins majeurs et d'incorporer plus tard les besoins 
secondares. Le cycle de vie iteratif evite la paralysie par 1' analyse. 

Stabilite des besoins et cycles de vie 

Le cycle de vie iteratif est souvent decrie par des informaticiens qui ont souffert 
de projets dans lesquels l'expression des besoins des utilisateurs n'etait pas 
stable. Ces informaticiens sont d'autant plus virulents que le cycle de vie iteratif 
leur apparait comme une perpetuelle invitation a la surenchere. Ils l'opposent par 
la au cycle en cascade, dans lequel les phases ont theoriquement une limite bien 
definie. 

Cette crainte a l'egard du cycle de vie iteratif n'est pas fondee. Quelle que soit la 
forme de cycle de vie, l'explosion des besoins est toujours la consequence d'un 
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mauvais depart. II n'y a pas tellement de nouveaux besoins, il y a surtout des 
besoins sous-estimes ou mal identifies. 

Le diagramme suivant represente le phenomene d'explosion des besoins. D'une 
part, les besoins ne sont pas stables, et d'autre part, les utilisateurs en rajoutent 
toujours de nouveaux. 



Pour regler le probleme de 1' explosion des besoins, il faut imperativement aider (il 
faudrait plutot dire forcer) les utilisateurs a articuler leurs besoins dans un cadre 
stable et structurant. Les cas d' utilisation apportent une tres bonne technique 
pour ce faire ; leur elaboration oblige les utilisateurs a imaginer comment ils 
comptent utiliser le futur systeme. Ceci reste difficile en l'absence d'elements 
concrets a critiquer, comme c'est le cas avec le cycle en cascade qui, dans ses 
premieres phases, ne produit que des documents. Le cycle de vie iteratif vient au 
secours des utilisateurs en leur fournissant des prototypes a evaluer. Les 
informaticiens peuvent de leur cote experimenter leurs choix de realisation en 
vraie grandeur. 

Des le debut du developpement, un cycle iteratif produit des prototypes 
documented qui peuvent etre evalues objectivement. II s'oppose au cycle en 
cascade qui ne fournit que des documents. Dans le premier cas, le logiciel est mis 
en avant ; dans le second cas, ce sont les sous-produits. A qualite d'encadrement 
egale, un cycle iteratif produit des resultats plus stables qu'un cycle lineaire. 

Le cycle en cascade ne secoue pas assez les utilisateurs ; les documents qu'il 
produit ne procurent qu'une illusion de progres ; rien ne dit que leur contenu 
satisfait reellement les besoins. Les revues de conception se passent bien, le 
projet suit le plan de developpement jusqu'a la phase d'integration. La, plus rien 
ne marche : de nombreuses reparations sont alors effectuees dans la precipitation, 



Besoins 




Figure 353 : Representation du phenomene d'explosion des besoins. 
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sans recul suffisant, et cela se traduit par des retards et un produit fragile et 
difficile a maintenir. 

Le diagramme suivant represente la courbe de connaissance des besoins dans 
une approche iterative. Tous les besoins ne sont pas necessairement connus des 
le debut ; la connaissance des besoins peut progresser avec les iterations. 
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Figure 354 : Exemple de progression dans la connaissance des besoins dans le cadre d'une 

demarche iterative. 

L' adoption de 1' approche iterative ne fait pas disparaitre tous les problemes par 
magie. L' approche iterative est seulement un outil pour mieux gerer les problemes. 



There is no silver bullet 40 



La documentation 

Les prototypes sont les principaux produits tangibles issus du cycle de vie 
iteratif, de sorte qu'il n'est pas necessaire de fournir des documents pour servir 
de support aux revues de validation de fin de phase, comme dans le cycle en 
cascade. 

II est neanmoins possible de construire une documentation conventionnelle 
lorsque celle-ci est exigee par contrat. Cette documentation est constitute de 
documents d'analyse et de conception par exemple dans le format normalise DoD 
2167a. 



Brooks, F. P. April 1987, No silver bullet, essence and accidents of software 
engineering. IEEE Computer. 
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La documentation n'est pas construite en une seule passe, mais graduellement, 
lors de chaque iteration. A la fin du developpement, les documents obtenus de 
maniere iterative ne se distinguent pas dans leur forme de ceux obtenus de 
maniere conventionnelle. En revanche, ils restituent une image fidele de l'etat final 
du projet avec lequel ils ont evolue de maniere synchrone. 

Le diagramme suivant montre que la documentation obtenue graduellement lors 
d'un developpement iteratif peut tres bien etre presentee comme issue d'un 
developpement conventionnel. Selon les lecteurs, 1' aspect iteratif du 
developpement gagne a etre occulte une fois le projet termine. 




Figure 355 : La documentation generee par un developpement iteratif est semblable dans sa 
forme a la documentation traditionnelle, mais reflete plus fidelement l'etat final du projet. 

Variantes du cycle iteratif 

II existe plusieurs variantes du cycle iteratif selon la taille du projet, la complexite 
du domaine et les choix d' architecture. 

Dans sa variante la plus simple, la forme du cycle de vie iteratif correspond a la 
lettre b. La forme en b a ete identified par Birrel et Ould 41 , qui reservaient l'iteration 
uniquement a la phase de maintenance. 

La forme en b est bien adaptee pour des applications de taille modeste ou pour 
des applications parfaitement definies, realisees dans le cadre d'une architecture 
eprouvee qui ne creera pas de surprises. 



Birrel N. D. et. Ould M. A. 1985, A Practical Handbook for Software 
Development. Cambridge University Press, Cambridge, U. K. 
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Les cycles y sont rapides et l'integration continue, de sorte que le principal 
avantage de cette forme iterative, par rapport a un cycle en cascade, est de 
supprimer l'effet big bang d'une phase d'integration localisee en fin de cycle. 

Le diagramme suivant represente l'enchainement des activites au sein d'un cycle 
de vie iteratif en b. L'iteration est centree sur la construction. 



Figure 356 : Cycle iteratif en b. Cette forme de cycle iteratif est bien adaptee pour les projets 

modestes ou bien definis. 

Le cycle en b concentre les iterations sur la construction. Lorsque tous les 
besoins ne sont pas connus des le depart, ou pour prendre en compte des 
retouches d' architecture, il est frequent de rajouter des boucles de rattrapage sur 
l'etude d'opportunite ou sur F elaboration. Le flot principal de l'iteration reste 
concentre sur la construction par increments, les flots secondares ayant pour 
vocation d'affiner l'analyse ou F architecture plutot que de les remettre en cause. 

Le diagramme suivant montre comment le cycle en b a tendance a s'ouvrir lorsque 
des retouches de conception ou d' analyse doivent etre apportees suite aux 
enseignements recueillis lors de la construction. 



Figure 357 : Cycle iteratif en b avec quelques retouches sur les activites en amont de la 
construction. L'iteration reste principalement concentree sur la construction. 
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Le cycle en b est tout a fait adapte pour les developpements bien circonscrits. 
Une grande part d'incertitude sur les besoins est plus grande, une architecture 
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partiellement determined ou un projet mene par plusieurs equipes en parallele, 
rendent preponderantes les branches secondaires : la forme du cycle se 
rapproche d'une lettre en O. Le cycle en O derive du cycle en spirale de Boehm 42 . 
II a ete decrit par Philippe Kruchten 43 et s'inspire d'une lettre ouverte de Mike 
Devlin 44 . 

Le diagramme suivant represente la forme d'un cycle de vie en O. L' iteration 
comprend 1' analyse et la conception. 

Ctudc d'opportunitif: 
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Figure 358 : Cycle de vie iteratif en O. Cette forme de cycle iteratif est bien adaptee pour les 

grands projets. 

Quelle que soit la forme du cycle de vie iteratif retenue, il convient de conduire 
1' analyse aussi loin que possible, sans etre paralyse par la recherche de 1' analyse 
parfaite. Le cycle iteratif, avec son exigence de livraisons regulieres de 
programmes executables, encourage les projets a decoller et a produire des 
resultats concrets. 

Evaluation des iterations 

Les criteres devaluation d'une iteration doivent etre definis avant de commencer 
l'iteration. Chaque iteration est decrite par un plan detaille, lui-meme inclus dans 
un plan de developpement general. Une iteration est marquee par des etapes 
intermediaires, comme des seances de relecture critique du code. Elles permettent 



Boehm B. W. May 1988, A Spiral Model of Software Development and 
Enhancement. IEEE Computer. 

43 Kruchten P. December 1991, Un processus de developpement de logiciel 
iteratif et centre sur V architecture. Proceedings of the 4th International 
Conference on Software Engineering, Toulouse, EC2, Paris. 

44 Mike Devlin est co-fondateur et president du conseil d' administration de 
Rational Software Corporation. 
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de mesurer les progres et d'entretenir le moral de l'equipe qui se concentre sur 
des objectifs a court terme. 

Le diagramme suivant represente une iteration d'un petit projet, delimitee par deux 
revues : la premiere, pour lancer formellement 1' iteration apres avoir verifie 
l'allocation des ressources et la deuxieme, pour valider l'iteration et autoriser la 
livraison du prototype correspondant. 



Le nombre d'etapes depend de la longueur de l'iteration. Pour de petites iterations 
- entre un et trois mois - il faut compter environ deux etapes : 

• la revue de depart qui fige les objectifs de l'iteration, les criteres d'evaluation 
et la liste des scenarios a realiser, 

• la revue d'evaluation qui valide les resultats de l'iteration par rapport aux 
criteres definis avant de derouler l'iteration. 

Pour des iterations plus longues, il faut prevoir plus de revues intermediaries pour 
1' approbation des plans de tests, la mise en place de 1' assurance qualite, etc. 

Les resultats de l'iteration sont evalues par rapport aux criteres d'evaluation 
definis lors de la planification de l'iteration. lis sont fonction des performances, 
des capacites et des mesures de qualite. II faut egalement prendre en compte les 
eventuels changements externes, comme 1' apparition de nouveaux besoins ou la 
decouverte des plans de la concurrence, et determiner s'il faut reprendre certaines 
parties du systeme et les assigner aux iterations restantes. 




Rcvuc do d6part 



Rcvuc devaluation 



Figure 359 : Exemple d'iteration delimitee par deux revues. 
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Figure 360 : Principaux produits et activites de revaluation d'une iteration. 

L'evaluation est une etape essentielle pour beneficier pleinement de l'approche 
iterative. II faut garder present a l'esprit qu'il vaut parfois mieux reviser les criteres 
plutot que modifier le systeme. Une iteration peut reveler qu'un besoin particulier 
n'est pas aussi important que prevu, qu'il est trop difficile a realiser ou trop cher a 
satisfaire. Dans ce cas, une analyse comparative entre le cout et le benefice doit 
etre menee. 

La planification des iterations 

II n'y a pas de reponse toute faite. Pour un projet de 18 mois environ, il y aura 
entre trois et six iterations. Les iterations ont toutes a peu pres la meme duree. 

Le diagramme suivant represente des exemples d'allocation de l'effort dans un 
developpement iteratif : 

• La courbe B correspond a une premiere iteration trop ambitieuse. Le projet B 
rencontre les desagrements du cycle en cascade : l'integration echoue, le 
developpement entre dans une periode d'instabilite et finit par depasser les 
delais, sans atteindre ses objectifs ou sans respecter ses imperatifs de qualite. 

• La courbe A correspond a un projet qui a consacre les deux premieres 
iterations a la mise en place d'une architecture stable, au prix de petites 
retouches, et qui connait une evolution iterative sans surprises. Le leger 
depassement d'achevement represente revolution des besoins qui ont ete 
pris en compte. 
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Figure 361 : Illustration de V impact de la planification des iterations sur le deroulement du 

projet. 

La premiere iteration est la plus difficile a conduire car elle demande la mise en 
place de l'ensemble de l'environnement de developpement et de l'equipe. Le 
projet rencontre generalement de nombreux problemes avec les outils, 
l'integration entre les outils, les relations au sein de l'equipe. 

Les equipes qui appliquent une approche iterative sont generalement trop 
optimistes. II faut rester modeste et ne pas attendre trop de la premiere iteration, 
faute de quoi les delais vont etre depasses, le nombre d' iterations eventuellement 
reduit et les benefices de 1' approche iterative limites. 

L'equipe perd generalement pas mal de temps a travailler avec le nouveau 
compilateur, a mettre en place la gestion de versions et de configurations, les 
tests de non-regression et le million d'autres choses qui doivent etre reglees lors 
de la premiere iteration. Pour la deuxieme iteration, tout rentre dans l'ordre, 
chacun sait comment proceder avec les outils et l'equipe peut se concentrer sur 
les fonctionnalites. 



Pilotage des projets objet 



Pourquoi parler de pilotage des projets objet ? Les projets objet demandent-ils 
une forme particuliere d'encadrement, et inversement, n'est-il pas possible de 
piloter les projets objet comme les projets classiques ? 

En fait oui et non. L'adoption des technologies objet n'implique pas 
obligatoirement de revoir les procedures de developpement en place. Neanmoins, 
il faut etre conscient que le seul moyen de reellement beneficier de 1' approche 
objet consiste a etablir une solution totalement objet. 

Cette evolution des pratiques de l'entreprise exige une adhesion totale des 
differents intervenants. 



256 - Modelisation objet avec UML 



II n'existe pas une forme de processus de developpement adaptee a tous les 
projets, tous les domaines d'application et toutes les cultures d'entreprise. Le 
processus de developpement decrit dans ce chapitre est defini de maniere 
generale. II appartient a chaque projet de 1' adapter en fonction de ses contraintes 
propres. 



Figure 362 : II appartient a chaque projet d 'adapter le processus abstrait decrit de maniere 
generate dans ce paragraphe. 

Le processus de developpement d'un logiciel peut etre observe selon deux points 
de vue complementaires : 

• la vue de l'encadrement qui se preoccupe des aspects financiers, strategiques, 
commerciaux et humains, 

• la vue technique qui se concentre sur l'ingenierie, le controle de la qualite et la 
methode de modelisation. 




Processus du projet A 



Processus du projet B 




Vue technique 




Figure 363 .-Points de vue portes sur le processus de developpement. 



La vue de l'encadrement 



La vue de l'encadrement represente le developpement du logiciel comme un 
enchainement de quatre phases : 
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• l'etude d'opportunite qui comprend l'etude du marche, la specification du 
produit final et la definition de la portee du projet ; 

• 1' elaboration qui correspond a la specification des particularites du produit, a 
la planification des activites, a la determination des ressources, a la 
conception et a la validation de l'architecture du logiciel ; 

• la construction qui regroupe la realisation du produit, 1' adaptation de la 
vision, de l'architecture et des plans, jusqu'a la livraison du produit ; 

• la transition qui rassemble la fabrication a grande echelle, la formation, le 
deploiement dans la communaute des utilisateurs, le support technique et la 
maintenance. 

Un cycle de developpement correspond a une passe au travers des quatre phases 
et donne une nouvelle generation du logiciel. 
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Figure 364 : Dans la vue de V encadrement, le developpement d'une generation du logiciel 
correspond a une passe au travers de quatre phases. 

Les progres sont mesures en termes d'avancement dans les phases. Certains 
logiciels demandent plusieurs cycles pour prendre en compte des ameliorations, 
des demandes de nouvelles fonctionnalites, etc. La phase de transition d'une 
generation donnee recouvre alors souvent la phase d'etude d'opportunite de la 
generation suivante. Dans le cas de grands projets, les cycles peuvent etre menes 
en parallele et plusieurs sous-systemes sont developpes independamment. 
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Figure 365 : Dans le cas de grands projets, des developpements de sous-systemes peuvent etre 

menes en parallele. 



La vue technique 

La vue technique se concentre sur la mise oeuvre et l'ordonnancement de toutes 
les activites techniques qui conduisent a la livraison d'une generation du logiciel. 

Le cycle de developpement est percu comme une suite d' iterations par lesquelles 
le logiciel evolue par increments. Chaque iteration debouche sur la livraison d'un 
programme executable. Le contenu d'une iteration doit etre utile pour le 
developpement ou pour l'utilisateur. II est determine en choisissant un sous- 
ensemble des fonctionnalites de l'application au sein des cas d'utilisation. 
Certaines livraisons sont purement internes, d'autres servent a demontrer l'etat 
d'avancement, certaines enfin sont placees chez l'utilisateur. D'iteration en 
iteration, le programme grandit en fonctionnalite et en qualite, jusqu'a ce qu'une 
iteration particuliere donne la premiere generation du logiciel. 

Les activites traditionnelles ne sont pas effectuees en sequence comme dans un 
cycle de vie en cascade ; elles sont distribuees - saupoudrees - sur les 
differentes iterations. Chaque iteration comprend des activites de planification, 
d'analyse, de conception, d' implementation, de test et d' integration, dont le 
nombre varie en fonction de la position de l'iteration dans le cycle. 

Le programme executable qui resulte d'une iteration est appele prototype. Un 
prototype est une etape concrete de la construction d'un logiciel. II fait la preuve 
tangible - mesurable - des progres realises. Un prototype est un sous-ensemble 
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de l'application, utile pour la formulation des besoins ou la validation des choix 
technologiques. Les prototypes s'enrichissent a chaque iteration. 

Le premier prototype a souvent pour seul objectif d'effectuer la preuve d'un 
concept d' application. II est developpe le plus rapidement possible, sans tenir 
compte des criteres de qualite habituels. Ce genre de prototype, le plus souvent 
jetable, est appele maquette. 

Les avant-dernieres iterations produisent les versions beta, generalement placees 
en test chez une selection d'utilisateurs bienveillants. 

La version livree a l'utilisateur est un prototype comme les autres, issu de la 
chaine des prototypes ; elle peut etre vue comme le dernier prototype de la 
generation courante et le premier prototype de la prochaine generation du 
systeme. 
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Figure 366 : Representation de la chaine des prototypes. 



Integration des deux points de vue 

Les deux points de vue sont synchronises a la fin de chaque phase, sur le resultat 
tangible d'une iteration. 

L'etude d'opportunite peut faire appel a un prototype pour determiner la viabilite 
d'un projet ou sa faisabilite technique. L'evaluation de la maquette executable, 
livree par l'equipe de developpernent, participe a la decision de poursuite ou non 
du projet, donnee a la fin de l'etude d'opportunite. 
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La phase d'elaboration a pour objectif essentiel de definir une architecture qui 
permette le developpement et revolution de 1' application. II est difficile de trouver 
une bonne architecture du premier coup, d'ou Finteret d'effectuer un certain 
nombre de prototypes d' architecture. L' elaboration se termine par la definition 
d'une base d' architecture, validee par un prototype d' architecture. 

La phase de construction progresse au rythme des prototypes de developpement, 
dont l'objectif premier est de mesurer les progres et de garantir la stabilisation de 
la conception. La phase de construction se termine par la livraison de versions 
preliminaires, les versions beta, qui sont placees chez des utilisateurs en vue 
d'etre testees en vraie grandeur, dans l'environnement de deploiement. 

La phase de transition debute par l'installation des versions beta sur site. Elle 
progresse au rythme des livraisons de versions qui viennent corriger les defauts 
detectes par les utilisateurs. Selon les organisations, la phase de transition 
s'arrete lorsque le logiciel est arrive a sa version de production, ou alors lorsque 
la prochaine generation est livree aux utilisateurs. 

II appartient a chaque projet de determiner le nombre d' iterations qu'il y a dans 
chaque phase ; le diagramme suivant donne un exemple typique. 



Iteration 



Tern as 



Iteration 




prelim in a ire 




lltjidlion 


► 


c'archilec:ure 




Iteration 


► 


c'aidnitac".ura 




Iteradon ds 


► 


de^eloppemert 




l:era:ion ds? 


► 


dc/cloppimcrt 




l:era:ion ds 


► 


de/eloppemeri 


► 


lleralior de 




transition 




Iteratior de 


► 


transition 


► 



R6st.ltat 



-+■ Maque:te 



->■ Pni'tatype d archi:ecture 



■> Prototype d archhecture 



-> P rota type tin d^veloppS'flent 



-+• Protnlype de developpeinent 



-> Vers b6ta 



-> Vers m beta 



-► Gi '^ration 



Phase 



Etude 

d'oppcrtLnite 



E abora:ion 



Construction 



Transition 



Figure 367 : Les deux points de vue sont synchronises en fin de phase. La fin d'une phase est 
marquee par la validation d'un prototype. 
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Gestion du risque dans un developpement iteratif 

Toute activite humaine comporte sa part de risques. Le developpement de 
logiciels n'echappe pas a cette regie. Les projets informatiques doivent gerer les 
gererafin de minimiser leurs consequences. 

L' analyse des risques consiste a evaluer le projet, la technologie et les 
ressources, dans le but de determiner et de comprendre la nature et l'origine des 
risques. Chaque risque est decrit brievement et les relations entre les risques sont 
soulignees. L'evaluation des risques determine dans quelle mesure les 
consequences d'un risque sont acceptables. 

Les risques doivent faire l'objet d'une description ecrite, pas necessairement 
dans un formalisme tres pousse. Tous les membres du projet doivent en prendre 
connaissance. Les risques doivent etres quantifies, sinon il est impossible de 
savoir si les risques ont ete elimines ou non. II ne faut jamais laisser trainer des 
expressions floues dans la documentation, comme : le systeme devra etre rapide, 
la capacite de la memoire sera suffisante, etc. 

II existe quatre grandes categories de risques : 

• les risques commerciaux : la concurrence peut-elle capturer le marche avant 
que le produit ne soit pret ? Vaut-il mieux sortir une livraison minimale pour 
occuper le terrain ? 

• les risques financiers : l'entreprise dispose-t-elle de capacites financieres 
suffisantes pour mener le projet a son terme ? 

• les risques techniques : la base technologique est-elle solide et eprouvee ? 

• les risques de developpement : l'equipe est-elle suffisamment experimentee et 
maitrise-t-elle les technologies mises en oeuvre ? 

Mais avant tout, il faut bien comprendre que le plus grand risque consiste a ne 
pas savoir ou sont les risques. II faut aussi se mefier des equipes plethoriques et 
prendre garde aux chefs de projet qui mesurent leur prestige au nombre de 
developpeurs sous leur responsabilite. II ne sert a rien d' avoir beaucoup de 
developpeurs : il faut avoir les bons et savoir les faire travailler en equipe. La 
gestion des risques regroupe toutes les activites requises pour construire un plan 
de reduction des risques et pour conduire ce plan a terme. 

Le plan de reduction des risques decrit, pour chaque risque identifie : 

• 1' importance par rapport au client, 

• 1' importance par rapport au developpement, 

• Taction entreprise et ses implications economiques, 

• le moyen de verifier que le risque a ete supprime ou reduit, et dans quelle 
mesure, 
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• les scenarios affectes par le risque, 

• 1' allocation a un prototype. 

La reduction du risque pilote les iterations dans le cycle de vie iteratif. Chaque 
iteration a pour objectif d'eliminer une part du risque global associe au 
developpement d'une application. Le diagramme suivant illustre le mecanisme de 
reduction du risque par les iterations. Chaque iteration est construite comme un 
petit projet, avec pour objectif la reduction d'une partie des risques identifies lors 
la definition du projet. 

Plannification dc I'itdration N 
Eva II. ation i n itia le d es risq ues CoOt cl dcila is 




Revision des risques „. 

Evalution des priorrtes Rl ^ 1Jes ellmmes 



Figure 368 : Chaque iteration est construite comme un petit projet, dedie a V elimination 
d'une partie des risques identifies lors de la definition du projet. 

En suivant l'approche en cascade, la reduction des risques est insignifiante 
jusqu'a ce que la phase d'integration commence. Les plus grands risques 
techniques sont lies a 1' architecture : performances (vitesse, capacite, precision), 
integrite des interfaces du systeme, qualite du systeme (adaptabilite, portabilite). 
Ces elements ne peuvent pas etre evalues avant qu'une quantite significative de 
code ait ete developpee et integree. Le diagramme suivant represente Failure de la 
courbe de decroissance du risque dans un developpement en cascade. Le risque 
reste eleve pendant la majeure partie du cycle de vie. 
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Figure 369 : Courbe de decroissance du risque dans un developpement en cascade. 

L'approche iterative identifie et traite les risques plus rapidement dans le cycle de 
vie, de sorte que le risque peut etre reduit de maniere significative des la phase 
d'elaboration. D'iteration en iteration, les prototypes executables valident les 
choix du projet de maniere concrete et mesurable, et le niveau de confiance dans 
1' application augmente. Le diagramme suivant montre la decroissance plus rapide 
du risque dans un developpement iteratif. La principale difference avec le 
diagramme precedent provient de l'axe des abscisses, gradue par les multiples 
iterations ; elles se concentrent toutes sur la reduction d'une part du risque 
global. 
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Figure 370 : Courbe de decroissance du risque dans un developpement iteratif. 

Chaque iteration est basee sur la construction d'un nombre reduit de scenarios 
qui s'attaquent d'abord aux risques les plus importants et determinent les classes 
et les categories a construire dans l'iteration. Les categories forment un espace de 
travail bien adapte aux developpeurs. 
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Les testeurs utilisent les memes scenarios pour construire le plan de test et les 
procedures de test de l'iteration. A la fin de l'iteration, 1'evaluation determine les 
risques qui ont ete elimines ou reduits. Le plan des prototypes est revise en 
consequence. 

Le diagramme suivant montre un exemple de repartition des risques entre deux 
prototypes consecutifs. II illustre l'effet d'une iteration en terme de reduction de 
risque. 
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Figure 371 : Une iteration a pour objectifla reduction du risque associe a une partie de 
V application. La partition des fonctionnalites de V application est realisee selon les cas 

d' utilisation. 



Chaque prototype explore une partie de 1' application dans le but de reduire une 
part des risques. Selon la nature des risques a etudier, les prototypes s'enfoncent 
plus ou moins profondement dans 1' architecture. 

Le diagramme suivant represente differentes sortes de prototypes : 

• le prototype d'lHM, limite a l'interface utilisateur, est souvent une maquette 
construite dans le but d'aider l'utilisateur a articuler l'expression de ses 
besoins ; 

• le prototype middleware (une couche logicielle intermediaire) teste et valide 
une couche de logiciel reutilisable, probablement achetee a l'exterieur ; 

• le prototype technologique verifie, par exemple, la qualite des encapsulations 
du materiel, ou des particularites des systemes d' exploitation ; 

• le prototype fonctionnel traverse toute 1' architecture ; il garantit la pertinence 
de l'ensemble des choix strategiques. 
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Figure 372 : Exemples de prototypes. Chaque prototype explore une partie de V application. 

Les prototypes sont enchaines une fois que 1' architecture a ete validee. Chacun 
de ces prototypes correspond a un ou plusieurs cas d' utilisation. A chaque 
iteration la couverture des besoins augmente. 

Le diagramme suivant montre comment quatre prototypes ont ete deployes pour 
developper une application. Les deux premiers prototypes ont du etre retouches, 
pour corriger 1' architecture ou pour prendre en compte de nouveaux besoins. 
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Figure 373 : Representation de la couverture des besoins, prototype par prototype. 

Le developpement iteratif ne consiste pas a recommencer eternellement le meme 
travail. Bien qu'il soit normal de refaire certaines parties 45 , la tendance generale 
est de conserver le resultat des iterations precedentes. Le premier prototype est 
jetable : d'ou la limite superieure placee a 100 % de retouche. Si le systeme 
reprend du code existant, la quantite de retouches doit etre plus faible. Une fois 



' Brooks, F. P. 1975, The Mythical Man-Month. Addison-Wesley, New York. 
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que 1' architecture est etablie et stabilised, les retouches restent faibles et bien 
localisees. La somme des retouches des iterations suivantes doit rester inferieure 
a 25 %. Les pourcentages, indiques dans le graphique suivant, se rapportent a 
l'ensemble du systeme et pas seulement a l'iteration la plus recente. 
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Figure 374 : Exemple de revolution des retouches avec le deroulement des prototypes. Une 
fois V architecture validee et stabilisee, la somme des retouches reste inferieure a 25 % du 

total. 



Gestion du risque phase par phase 

Chaque phase du developpement apporte sa contribution a la reduction des 
risques, avec a chaque fois un eclairage different : 

• V etude d' opportunity essaie de delimiter les risques du projet, en 
construisant un prototype pour valider les concepts ; 

• V elaboration commence par reduire les risques d' incomprehension entre les 
utilisateurs et les developpeurs : elle developpe une vision partagee de la 
portee du projet et explore des scenarios avec les utilisateurs et les experts du 
domaine. Dans un deuxieme temps, V elaboration valide les choix 
d'architecture. L' architecture est raffinee par les iterations suivantes, au 
besoin ; 

• la construction est le siege de la fabrication incrementale de 1' application. 
L' integration progressive des divers composants supprime les risques de 
discordance rencontres dans les phases dediees specifiquement a 
l'integration, en fin de developpement en cascade ; 



4 - Encadrement des projets objet - 2S7 



• la transition : les risques de prise en main du logiciel sont reduits par le 
deploiement graduel de 1' application en phase de transition, et cela d'autant 
plus lorsque les utilisateurs ont ete impliques des les phases precedentes ; 

• le post-deploiement : la maintenance, corrective ou evolutive, est effectuee 
dans le meme cadre de developpement que la construction, par iteration et 
fabrication de nouveaux prototypes. La maintenance est une evolution 
normale du produit, similaire a la construction. Les risques de degradation de 
l'architecture et de la conception s'en trouvent fortement reduits. 

Exemples de risques 

Tous les projets rencontrent des risques dont le nombre varie selon la taille, la 
complexite, le degre de nouveaute du projet et les qualifications de l'equipe de 
developpement. 

Certains risques sont frequents, du fait de la naivete des participants, des 
relations faussees entre client et fournisseur, de l'instabilite des besoins, etc. 

Les grandes causes d'echec des projets sont souvent liees : 

• dans le cas de tres grands projets, a la situation geopolitique bien plus qu'aux 
aspects techniques, 

• a l'absence d'une reelle vision de l'architecture, de sorte que le logiciel n'est 
pas integrable, 

• aux mauvaises relations au sein de l'equipe de developpement, 

• a l'absence de motivation, du fait d'echeances trop lointaines ou mal definies, 

• au manque de visibilite sur le projet, a la fois des developpeurs qui ne 
percoivent pas l'image globale, et de l'encadrement qui, sans informations 
precises, pilote dans le brouillard, 

• a un manque de personnel qualifie, suffisamment forme aux diverses 
technologies mises en oeuvre, 

• a un exces de personnes dans le projet, principalement dans les grandes 
organisations, ou le prestige du chef de projet se mesure au nombre de 
developpeurs places sous ses ordres, 

• au manque d'implication de l'utilisateur dans le processus de developpement, 

• au manque de soutien de toute l'organisation, provoque par le manque de 
conviction d'un groupe donne, comme l'assurance qualite ou l'encadrement 
intermediaire, 

• a la sous-estimation du budget de la formation et du tutorat, necessaires a 
tout projet qui aborde de nouvelles technologies, 
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• a la sous-estimation des delais, ce qui cause souvent la suppression 
d' iterations intermediaries, et par suite, le retour aux travers du cycle en 
cascade, 

• a la sous-estimation de l'ampleur du projet, manifested entre autres par 
l'instabilite des besoins, 

• a la technologie selectionnee, quelquefois par simple effet de mode, 

• a la dependance par rapport a d' autres developpements, effectues en parallele. 

Le tableau suivant resume les dix principaux risques recurrents et les actions a 
entreprendre pour les reduire. 



Risque 


Impact 


Resolution 


Integration trap complexe 


Qualite 


Centrage sur I'architecture 


Absence de convergence 


Cout 


Middleware 




Delais 


Developpement iteratif 


Demotivation 


Qualite 


Developpement iteratif 




Cout 


Objectifs proches 




Delais 


Planification des besoins 


Environnement de developpement 
inadapte 


Cout 
Delais 


Investissement dans des outils 
integres 


Utilisateurs defavorables 


Cout 


Implication precoce des utilisateurs 




Delais 


Demonstration de prototypes 


Technologie trop complexe 


Cout 


Centrage sur 1'architecture 




Delais 


Achat de competences externes 


Activites manuelles trop lourdes 


Cout 


Automatisation par des outils integres 


Inadequation des composants 
reutilisables achetes 


Delais 


Prototypes 


Performances insuffisantes 


Qualite 


Independance par rapport au materiel 


Exces de bureaucratie 


Delais 


Centrage sur les prototypes, pas sur 
la documentation 


Fonctions inadaptees 


Qualite 


Prototypes 



Figure 375 : Resume des dix principaux risques recurrents et des actions a entreprendre pour 

les reduire. 



Chaque organisation ou projet devrait definir une liste de criteres pour determiner 
quelles fonctionnalites doivent etre developpees dans une iteration donnee. Le 
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tableau suivant decrit des exemples de criteres suffisamment generaux pour etre 
appliques a tous les projets. 



Critere 


Description 


Interet 


Degre de necessite de l'element pour les utilisateurs 


Cout de fabrication 


Estimation de la difficulte de developpement de l'element par les 
developpeurs 


Nouveaute 


L'element est-il totalement inconnu ? 


Interfaces necessaires 


De quoi I'element a-t-il besoin ? 


Politique 


Comment sera pergue la presence ou I'absence de I'element ? 


Technologie 


Les developpeurs maTtrisent-ils les technologies necessaires ? 


Planification 


L'element conditionne-t-il la livraison de prototypes ? 


Tremplin 


L'element facilite-t-il le developpement d'autres elements ? 



Figure 376 : Exemples de criteres d' appreciation des risques pour la determination des 

iterations. 



Constitution de lequipe de developpement 

II existe quelques rares informaticiens virtuoses, mais quelles que soient les 
qualites des individus, il arrive un moment ou l'ampleur de la tache a accomplir est 
telle que l'effort individuel ne suffit plus. II convient alors de travailler de concert, 
de coordonner les efforts et de rechercher la performance collective a partir des 
capacites moyennes de chacun. 

Le choix des personnes qui constituent une equipe de developpement determine 
fortement le deroulement du projet. Au-dela des aspects techniques, le succes 
d'un projet depend en grande partie des facteurs humains. Un bon processus de 
developpement permet precisement de retirer la quintessence d'une equipe de 
developpement, de maniere reproductible et controlee. Les membres d'une equipe 
efficace doivent d'une part etre complementaires, et d' autre part etre bien 
conscients de leur role dans le processus de developpement. II appartient au chef 
de projet de mettre sur pied cette equipe de personnes, puis d'entretenir le moral 
des troupes pendant 1' ensemble du developpement. 

De maniere generale, un processus de developpement de logiciel peut se 
decomposer en trois sous-processus : 

• le developpement informatique proprement dit, 

• la logistique qui pourvoit aux besoins du developpement informatique, 
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V interface avec le reste du monde qui isole le developpement des 
perturbations externes. 



Ivar Jacobson a montre comment les processus des entreprises peuvent se 
modeliser avec des cas d'utilisation 46 . La figure suivante utilise ce formalisme 
pour illustrer les trois sous-processus du developpement. 



Developpement 



o 

Informatique 
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Logistique 

Interface 
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Figure 377 : Exemples de representation des sous-processus du developpement dans un 
diagramme de cas d'utilisation. 

L'equipe de developpement est organisee par rapport aux cas d'utilisation decrits 
precedemment. Les differents intervenants sont represented par des acteurs qui 
interagissent avec les trois cas d'utilisation identifies. 

Le developpement informatique 

Le developpement informatique est conduit par les trois acteurs suivants : 

• I'architecte definit la forme generale du logiciel. II est egalement responsable 
de la definition et de l'ordonnancement des iterations ; 

• les abstractionistes (de 1' anglais abstractionist) identifient les objets et les 
mecanismes qui permettront de satisfaire les besoins de l'utilisateur ; 

• les developpeurs maitrisent les technologies et realisent les abstractions 
identifiees par les abstractionistes. 



Jacobson I., Ericson M., Jacobson A. 1994, The Object Advantage, Business 
Process Reengineering with Object Technology. Addison Wesley. 
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Figure 378 : Representation des acteurs du developpement informatique proprement dit. 

La logistique 

La logistique interagit avec les acteurs suivants : 

• le chef de projet compose l'equipe, gere le budget et les personnes, et 
coordonne les diverses activites ; 

• Vanalyste est un expert du domaine, charge de comprendre les besoins des 
utilisateurs ; 

• Vintegrateur assemble les elements produits par les developpeurs, et ce 
durant le developpement dans le cas d'un projet objet ; 

• le qualiticien evalue tous les elements produits par le developpement et 
dirige les tests du systeme ; 

• le documentaliste redige la documentation a destination de l'utilisateur ; 

• V administrateur- systeme gere et entretient le pare materiel utilise par le 
projet ; 

• L'outilleur construit et adapte les outils logiciels qui forment l'environnement 
de developpement ; 

• le bibliothecaire assure l'archivage et la preservation de tous les artefacts du 
developpement et de leurs regies de production. 
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Figure 379 : Representation des acteurs de la logistique. 

L' interface 

L'interface interagit avec les acteurs suivants : 

• le chef de projet assure l'interface entre l'equipe de developpement et le reste 
du monde ; 

• le chefde produit supervise une ligne de produits ; il coordonne les activites 
de marketing, de formation et de support technique ; 

• le financier controle 1' allocation du budget et sa bonne utilisation ; 

• / 'utilisateur/ client participe a des revues de prototypes ; 

• le support technique resout ou contourne les problemes rencontres par les 
utilisateurs. 




Support 

technique Financier 



Figure 380 : Representation des acteurs de l'interface. 
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Les roles decrits precedemment peuvent etre joues par la meme personne. Dans 
les petites organisations, il est frequent que le chef de projet remplisse egalement 
les roles d'architecte et d'analyste. De meme, les developpeurs et les 
abstractionistes sont souvent confondus. 

Description detaillee des phases 

Ce paragraphe detaille les differentes phases du cycle de developpement selon le 
point de vue general adopte par l'encadrement. Les phases apportent une vision 
structuree dans le temps, bien adaptee a la gestion des aspects contractuels et 
financiers. 

L' etude d'opportunite 

L' etude d'opportunite n'est generalement pas menee par les informaticiens, mais 
par des specialistes de 1' etude des marches et de 1' analyse de la concurrence. lis 
essaient de determiner si la construction d'un nouveau systeme ou une 
amelioration majeure d'un systeme existant est economiquement justifiee et 
presente un interet pour l'entreprise. 

La premiere operation consiste a se doter d'une vision generale du produit afin de 
mieux le caracteriser et de degager des elements d' appreciation. Cette vision peut 
se resumer par la formule suivante 47 : 



Vision = Quoi + Pour qui + 
Com bien 



Les differentes composantes se definissent ainsi : 

• Quoi exprime les grandes lignes du produit ; 

• Pour qui determine la population cible ; 

• Combien estime le prix que les acheteurs du produit seront disposes a payer. 

La vision generale du projet est exprimee dans un cahier des charges preliminaire, 
dans un cahier des non-objectifs qui precise ce que le projet n'est pas, et dans un 
argumentaire financier qui donne les premiers elements economiques, par exemple 
en termes d'estimation du retour sur investissement. 

Ces differents elements peuvent etre difficiles a apprecier en 1' absence d'elements 
de mesures tangibles. C'est pourquoi l'etude d'opportunite se base souvent sur 
une analyse preliminaire du domaine (10 a 20 % des classes). Lorsque les 
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incertitudes sur la faisabilite d'un projet sont elevees, il est frequent de conduire 
un prototype conceptuel. Son but premier est de degager des elements concrets 
pour evaluer les risques lies aux fonctionnalites attendues, aux performances 
requises, a la taille ou a la complexite du sujet, ou encore a l'adoption de 
nouvelles technologies. A partir de la, le concept du produit est valide ou non. 

Ce genre de prototype ne respecte pas les regies habituelles de developpement. II 
recherche avant tout un resultat rapide, sans insister sur la fiabilite ou la rapidite 
d'execution. C'est avant tout une maquette jetable dont le code ne rentre pas 
dans 1' application finale. Elle gagne a etre realisee dans un environnement de 
prototypage rapide, comme Smalltalk. Certaines applications sont developpees 
integralement a partir du premier prototype. Pour ce faire, des outils de 
developpement rapide d' application (RAD) sont utilises. Cette approche 
fonctionne pour des projets modestes, mais ne se prete guere a des systemes 
plus consequents. 

A ce stade, l'equipe est constitute d'un petit nombre de personnes qui entourent 
l'architecte du systeme ou l'architecte du logiciel. Elles continueront de participer 
au developpement du projet. 

Par la suite, une fois que la vision du produit est definie et que les risques 
inherents au projet ont ete identifies dans leurs grandes lignes, l'etude 
d'opportunite essaie d'estimer le cout du projet et le retour sur investissement. 

L'estimation des couts et le retour sur investissement 

La determination du retour sur investissement est assez difficile a effectuer dans 
le cas de l'informatique, en raison essentiellement de l'immaterialite des logiciels 
et du manque d'elements objectifs pour apprecier a priori leur cout. 

II faut rechercher un equilibre entre la fiabilite de l'estimation des couts et le delai 
necessaire pour produire cette estimation. L'estimation fausse immediate ou le 
cout exact connu a la fin du developpement n'etant pas acceptables, il est 
judicieux de decomposer l'estimation en plusieurs etapes, afin de l'affiner 
progressivement. 

La figure suivante represente, qualitativement, la precision de l'estimation du cout 
d'un developpement logiciel. 
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Figure 381 : Evolution de la precision de V estimation du cout d'un projet. 



Du fait du faible niveau de visibilite sur les besoins reels et sur la nature des 
risques durant l'etude d'opportunite, il est fort peu realiste d'essayer d'estimer 
precisement les ressources necessaires au projet. 

Neanmoins, cette estimation est frequemment demandee par le client. II faut alors 
expliquer a celui-ci que la seule maniere d'avoir une bonne idee du cout, c'est de 
financer une premiere tranche jusqu' a la fin de la phase d' elaboration. A la lumiere 
de l'information recoltee, il pourra decider de poursuivre ou non l'effort de 
developpement, avant d'aborder la montee en charge de la phase de construction. 

L'approche objet seule ne permet pas d'evaluer le cout final plus rapidement que 
les approches traditionnelles. En revanche, associee a une demarche iterative, elle 
permet de garantir une determination plus precise de ce cout a partir de la phase 
d'elaboration. 

Pour un petit projet, l'etude d'opportunite est souvent reduite a un cahier des 
charges. Pour un projet moyen, d'une annee environ, l'etude d'opportunite - 
fabrication du prototype incluse - prend approximativement un mois. Pour un 
gros projet, le prototype devient un petit projet a part entiere, souvent denomme 
demonstrateur, et passe lui-meme par les differentes phases enoncees plus haut. 

La phase d'elaboration 

La phase d'elaboration commence par l'analyse des besoins et par la modelisation 
du domaine. Elle a pour objectif de definir les choix d' architecture, d' explorer et de 
reduire les risques du projet, et finalement de definir un plan complet qui quantifie 
les moyens a mettre en ceuvre pour mener a bien le developpement. 

La phase d'elaboration est conduite par une equipe restreinte, emmenee par 
l'architecte logiciel. Elle est constituee d'un petit groupe de developpeurs et d'un 
ou deux experts du domaine ou d'utilisateurs. II est souvent judicieux d'adjoindre 
un representant de l'equipe de test et d'assurance qualite, un outilleur 
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(responsable de la mise en place de l'environnement de developpement) et un 
documentaliste (responsable de la redaction de la documentation). 

Activites conduites en phase d'elaboration 

L' analyse des besoins est basee principalement sur l'etude des cas d'utilisation, 
sans pour autant exclure toutes les autres techniques qui pourraient aider les 
utilisateurs a articuler puis a formuler leurs desirs. 

Les cas d'utilisation sont exprimes dans la terminologie des utilisateurs, sous une 
forme textuelle, loin de tout formalisme informatique. La transition vers une 
representation plus informatique est effectuee par les analystes. lis transforment 
les cas d'utilisation en collaborations entre objets du domaine de l'application. 
Une collaboration reste comprehensible par les utilisateurs. II faut prealablement 
leur expliquer que les objets representent une entite du monde reel, autrement dit 
de leur monde, et que ces objets collaborent pour construire les fonctions 
representees par les cas d'utilisation. 
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Figure 382 : Exemple de realisation d'un cas d'utilisation par une collaboration entre trois 

objets. 

Au fur et a mesure de l'etude detaillee des cas d'utilisation, le modele du domaine 
est mis a jour pour prendre en compte les nouvelles classes identifiees dans les 
collaborations qui servent de support aux differentes interactions. Une deuxieme 
passe d' analyse, apres 1' analyse du domaine, recherche des abstractions et des 
scenarios plus generaux. Elle degage des classes abstraites qui serviront de 
specifications pour l'ecriture de mecanismes generiques. 

La phase d'elaboration donne naissance aux produits suivants : 

• la description du comportement du systeme, exprimee sous la forme de cas 
d'utilisation, le contexte du systeme, les acteurs, les scenarios et un modele 
des classes du domaine (80 % des classes) ; 
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• une architecture executable, un document de description de 1' architecture et 
une revision de la vision du projet et de la description du risque ; 

• un plan de developpement complet pour l'ensemble du projet ; 

• un plan detaille des iterations, les criteres d'evaluation et le cahier des charges 
de chaque iteration et les resultats de 1' assurance qualite ; 

• eventuellement un manuel utilisateur preliminaire. 
Pour les projets de taille moyenne, il y a typiquement : 

• quelques dizaines de cas d' utilisation ; 

• une centaine de scenarios principaux ; 

• quelques centaines de scenarios secondaires ; 

• entre 50 et 100 classes dans le domaine. 

Conseils pratiques sur Pelaboration 

N'importe quelle application devrait pouvoir recuperer suffisamment de 
composants reutilisables pour realiser de 10 a 30 % de son implementation. Les 
frameworks et les solutions cles en main permettent d'envisager un taux de 
reutilisation de l'ordre de 60 % pour un meme type d'application et un meme 
domaine. 

La duree de la phase d' elaboration est done tres variable. Elle depend beaucoup 
des types d'application et des choix d' infrastructure. Pour un projet d'un an, cette 
phase dure entre deux et quatre mois. 

Dans tous les cas, il faut imperativement eviter la paralysie par 1' analyse, e'est-a- 
dire de perdre trop de temps a rechercher une analyse parfaite. II vaut mieux se 
jeter a l'eau (e'est-a-dire passer a la conception de 1' architecture) lorsqu' environ 
80 % des scenarios principaux ont ete examines. 

Lors de l'etude des scenarios, il ne faut pas non plus aller trop loin dans les 
details au risque de s'enfoncer trop tot dans la conception et par suite de 
manquer d' abstraction dans les solutions mises en oeuvre. 

La phase de construction 

Cette phase a pour objectif de developper un produit logiciel pret pour la 
transition dans la communaute des utilisateurs. Dans les cycles iteratifs en b, la 
phase de construction correspond a la mise en oeuvre effective des iterations. 
Certaines iterations sont purement internes, d'autres sont egalement visibles a 
l'exterieur du projet. Chaque iteration produit la livraison d'un prototype 
executable. 

Un prototype force la fin d'une iteration et oblige l'equipe de developpement a 
fournir un resultat concret, mesurable. Un prototype est stable et autosuffisant ; 
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c'est une version executable du systeme, conduite comme un petit projet et 
accompagnee de tous les produits necessaires pour son exploitation. 

La realisation d'une iteration regroupe les activites suivantes : 

• identification des scenarios a completer ou a reprendre dans 1' iteration, en 
fonction de l'etude des risques et des resultats de l'iteration precedente ; 

• assignation de taches precises a l'equipe de developpement pour arriver au 
bout de l'iteration ; 

• definition des criteres devaluation de chaque iteration, des points de controle 
et des delais ; 

• redaction de la documentation pour l'utilisateur et de la documentation de 
deploiement (notes de livraison, notes d'installation). 

Le flot de livraisons se caracterise par : 

• une augmentation reguliere des fonctionnalites, mesuree par le nombre de 
nouveaux scenarios pris en compte par chaque iteration ; 

• une plus grande profondeur, mesuree par le degre de realisation du modele du 
domaine et des mecanismes ; 

• une plus grande stabilite, mesuree par la reduction dans les changements 
apportes aux modeles ; 

• l'ajustement continu du plan du projet ; 

• 1'evaluation de chaque iteration, avec les resultats des tests et de l'assurance 
qualite. 

Avec la montee en charge de la construction, l'equipe est au complet. Dans les 
grands projets, plusieurs increments peuvent etre developpes en parallele. En 
regie generale, 80 % de l'equipe travaille au developpement d'une livraison, alors 
que les 20 % restant explorent les nouveaux risques et preparent la mise en 
chantier des livraisons suivantes. 

Pour un projet modeste, cette phase dure entre 2 et 3 mois ; pour un projet 
typique, elle dure entre 6 et 9 mois en moyenne. La duree totale des projets objet 
est aujourd'hui d'une annee, avec une petite equipe de 5 ou 6 developpeurs. 
Dans le cas de tres gros projets, chaque sous-systeme se comporte comme un 
projet et possede alors ses propres iterations, au sein d'un cycle de vie iteratif 
en O. 

La gestion du changement 

Dans un cycle de vie iteratif, les artefacts de developpement murissent avec les 
iterations. Le projet est done confronte a un important probleme de gestion de 
coherence, du fait des nombreuses versions de chaque element. Cette gestion de 
la coherence peut etre assuree avec succes et a un cout raisonnable uniquement 
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si des outils de gestion de versions et de configurations sont totalement integres 
dans le processus de developpement. 

Dans les projets modestes, la gestion des changements concerne principalement 
le code et la documentation. Dans les projets plus ambitieux, il faut se preoccuper 
de la gestion du changement dans l'ensemble de l'environnement de 
developpement, depuis les versions des logiciels, comme les compilateurs ou les 
systemes d' exploitation, jusqu'au materiel lui-meme. Dans les cas extremes, par 
exemple pour certains projets militaires ou aeronautiques, l'ensemble de 
l'environnement de developpement (logiciel et materiel) est conserve, sans 
aucune modification, pendant toute la duree de vie du systeme ! 

Les principaux types de changements apportes au logiciel sont les suivants : 

• l'ajout de classe ou de collaboration avec une classe ; 

• le changement de 1' implementation des operations d'une classe ; 

• le changement de la representation d'une classe ; 

• la reorganisation de la structure de classes ; 

• le changement de l'interface d'une classe. 

Les trois premiers types de changements sont frequents dans la phase de 
construction. Dans les dernieres iterations, les deux derniers types indiquent que 
la conception n'est pas stable. 

Avec le temps, les changements doivent etre de plus en plus localises (du fait de 
1' encapsulation). Les changements d' architecture sont les plus couteux en terme 
de retouches. 

Conseils pratiques sur la construction 

Chaque livraison donne aux developpeurs une satisfaction liee a la notion de 
travail accompli. Les livraisons constituent des sous-objectifs relativement faciles 
a atteindre, dans un delai raisonnable par rapport a la duree totale du projet. De ce 
fait, le moral de l'equipe reste au beau fixe, meme si la demarche par prototypes 
oblige a s'attaquer aux problemes des le depart. 

Chaque livraison fournit egalement a l'encadrement un point de controle objectif 
sur l'etat d'avancement du projet. Chaque prototype est un pas en avant vers la 
satisfaction des besoins. 

Enfin, chaque livraison redonne confiance aux utilisateurs qui recoivent par 
l'examen du prototype un retour tangible, dont ils peuvent directement transposer 
les benefices dans leur travail quotidien. Ceci suppose de ne pas jeter une 
livraison en pature aux utilisateurs, sans avoir au prealable defini avec eux la 
portee du prototype. II faut imperativement que les utilisateurs comprennent 
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qu'un prototype est une etape, pas un systeme complet, sinon les frustrations 
peuvent etre grandes. 

En cas d'urgence, il vaut mieux reporter des fonctionnalites que manquer un 
rendez-vous avec les utilisateurs. Tout prototype demontrable, meme incomplet, 
augmente le niveau de confiance des utilisateurs, et par suite du client. II faut 
toutefois prendre garde a I'effet congere qui se caracterise par une accumulation 
de fonctionnalites non satisfaites, toujours remises a la prochaine livraison. II faut 
essayer de tenir le plan des livraisons car la tendance naturelle est de repousser 
les livraisons en raison du retard pris par rapport a la realisation des 
fonctionnalites. En repoussant la fin des iterations, et par suite la livraison des 
prototypes, le danger est grand de revenir au modele en cascade et de perdre les 
avantages de la demarche iterative. 

Les categories permettent d'allouer les responsabilites dans l'equipe. Les petits 
changements sont pris en compte a l'interieur d'une classe ou d'une categoric 
Les grands changements demandent la coordination entre les responsables de 
chaque categorie et une remontee de la decision au niveau de l'architecte. II est 
normal de devoir jeter du code en phase de construction. En revanche, au-dela de 
25 % de changements cumules dans les livraisons de construction, 1' architecture 
doit etre consideree comme instable. L'instabilite de 1' architecture est 
generalement le signe d'une phase d'elaboration qui n'a pas donne une place 
suffisante a 1' experimentation. 

La phase de transition 

La phase de transition consiste a transferer le logiciel dans la communaute de ses 
utilisateurs. Cette phase est d'une complexite variable selon le type 
d'application ; elle comprend la fabrication, l'expedition, 1' installation, la 
formation, le support technique et la maintenance. L'equipe de developpement se 
reduit a un petit groupe de developpeurs et testeurs, assistes a temps partiel par 
l'architecte, garant de la coherence de l'ensemble, et par un documentaliste 
responsable de la mise a jour de la documentation. Le relais est passe au 
personnel du support technique, ainsi qu'aux formateurs et aux commerciaux. 

En phase de transition, le developpement initial est presque termine ; tous les 
artefacts ont atteint suffisamment de maturite pour etre distribues largement vers 
deux categories de destinataires : les utilisateurs et les responsables du projet. 

Les principaux produits a destination des utilisateurs comprennent : 

• des programmes executables, les versions beta puis definitives ; 

• les manuels pour l'utilisateur ; 

• la documentation de deploiement et d' installation. 

Les principaux produits a destination des responsables du projet regroupent : 

• les modeles revises ; 
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• les criteres devaluation de chaque iteration ; 

• la description des livraisons ; 

• les resultats de 1' assurance qualite ; 

• les resultats de 1' analyse post-mortem des performances du projet. 

La duree de la phase de transition est tres variable selon le critere de fin de phase. 
Si la fin est indiquee par le client au cours d'un processus de recette, la transition 
dure au maximum un mois pour un projet d'une annee. En revanche, si la fin du 
projet correspond a la fin de la vie du projet, la transition peut etre beaucoup plus 
longue. 

Conseils pratiques sur la transition 

La difficulte de cette phase est inversement proportionnelle a la qualite du produit 
et au degre de preparation des utilisateurs. Tous les produits necessitent une 
formation. II ne faut pas negliger la phase d' installation du produit ; une 
installation difficile peut decourager les utilisateurs et reduire leur confiance dans 
le produit. 

Pour un systeme de remplacement, beaucoup d'efforts sont necessaires pour 
mettre en place le nouveau systeme en parallele avec le systeme existant. 

Dans certaines organisations, l'equipe de maintenance et l'equipe de 
developpement sont nettement dissociees. Cette situation n'est pas optimale car 
elle engendre une rupture trop nette dans le cycle de developpement. Elle induit 
surtout un moment de flottement dans le partage des responsabilites, entre les 
developpeurs initiaux et les developpeurs de maintenance. II est plus judicieux 
d' assurer un recouvrement entre les deux equipes, en incluant des personnes du 
support technique et de la maintenance des le debut du projet et en assignant a 
temps partiel quelques developpeurs initiaux dans l'equipe de maintenance. 

Cycles de developpement post-deploiement 

Pour la plupart des produits logiciels, le deploiement marque le debut d'une 
periode de maintenance et d' amelioration. Cette periode se caracterise par la 
repetition du cycle de developpement, de l'etude d'opportunite jusqu'a la 
transition. L' importance relative de chacune de ces activites peut changer. Ainsi, 
dans un simple cycle de maintenance, il n'y a pas normalement d' impact sur 
1' architecture, tant que les modifications restent bien encapsulees. 

Chaque iteration demarre en etablissant une liste de priorites de reparation et en 
designant les equipes de developpement. Elle se termine par la livraison d'une 
version du systeme qui corrige les defauts identifies precedemment. La transition 
inclut la mise a jour de la documentation a destination des utilisateurs et la 
description des defauts corriges. 
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Conseils pratiques sur le post-deploiement 

II faut imperativement corriger les defauts afin de satisfaire les attentes legitimes 
des utilisateurs. II faut essayer en plus de satisfaire leurs nouveaux besoins, 
eventuellement au moyen de nouvelles technologies : un logiciel qui n'evolue 
plus devient sans interet. Pour ce faire, il faut se focaliser sur la conservation de 
l'integrite de l'architecture sinon l'entropie prend le dessus : petit a petit, le cout 
des changements augmente, la conception se complique et la maintenance 
devient de plus en plus difficile. 

Dans tous les cas, quelles que soient les mesures prises, les resolutions affichees 
et la bonne volonte des equipes de developpement et de maintenance, il arrivera 
un temps ou le logiciel devra etre jete et remplace par un autre. Les logiciels 
portent en eux les raisons de leur mort, et leur esperance de vie... 

Repartition des activites par rapport aux phases 

L'importance de chaque activite de developpement varie d'une phase a une autre. 
II n'y a pas de correspondance directe entre les phases de la vue de 
l'encadrement et les phases classiques d'un cycle en cascade. Au contraire, les 
activites comme l'analyse et la conception sont etalees sur plusieurs phases de la 
vue de l'encadrement. Les activites se distribuent sur les cycles et leur debut et 
fin ne correspondent pas aux limites des phases de la vue de l'encadrement. 

En fait, le point important est la densite d' activite realisee dans chaque phase de 
la vue de l'encadrement. 
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Figure 383 : Repartition typique des activites au sein des phases de la vue de l'encadrement. 
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La figure precedente montre que : 

• la planification est effectuee tout au long des phases ; 

• l'analyse est concentree principalement dans la phase d' elaboration, bien 
qu'une part d'analyse puisse deja etre conduite en phase d'etude 
d'opportunite et que l'analyse soit affinee en phase de construction ; 

• la principale partie de l'architecture est determinee dans la phase 
d' elaboration ; 

• la realisation (qui comprend egalement les tests unitaires) commence en phase 
d'elaboration (pour les elements d' architecture) et culmine en phase de 
construction ; 

• la maintenance debute des que la premiere version du logiciel a ete definie, 
generalement en phase d'elaboration ; 

• les tests et les mesures de qualite se repartissent sur toutes les phases et 
concernent tous les prototypes ; 

• la gestion des changements (versions et configurations) enregistre l'histoire 
de tout le projet. 

II n'y pas de phase d'integration proprement dite : l'integration est continue, le 
logiciel est integre par construction. 

Effort relatif par activite 

Le diagramme suivant illustre une situation typique, representative d'un projet 
objet moyen (d'une annee environ, avec une petite equipe d'environ cinq 
personnes). II decrit une repartition typique de l'effort par rapport aux activites. 

Dans le but de repartir l'effort selon les differentes activites, les postulats 
suivants sont etablis : 

• la planification inclut les activites de pilotage de projet, les plans de 
developpement, la mesure des progres et le controle des ressources du 
projet ; 

• l'analyse comprend le developpement des modeles objet, des modeles 
utilisateurs, la specification de la vision du projet et la description des criteres 
d' evaluation ; 

• l'architecture inclut la realisation des fondements du logiciel, la conception 
generale de toute 1' application et la construction des mecanismes communs ; 

• 1' implementation regroupe toutes les activites de conception detaillee, le 
codage et les tests unitaires ; 

• la maintenance comprend les changements apportes au logiciel, une fois place 
sous gestion de versions et de configurations ; 
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• les tests et 1'evaluation comprennent les activites necessaires pour demontrer 
que le logiciel atteint les objectifs fixes et mesures par les criteres ; 

• la gestion du changement memorise les etats consecutifs de tous les artefacts 
de developpement. 
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Figure 384 : Repartition typique de V effort par rapport aux activites. 



Effort relatif par phase 

L'effort est reparti differemment selon les phases et cette repartition peut varier 
considerablement avec les caracteristiques du projet. Le diagramme suivant 
montre une situation typique, representative d'un projet de taille moyenne. La fin 
de la phase de transition est marquee par la disponibilite generale du produit. 
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Figure 385 : Repartition typique de I' effort par rapport aux phases. 

Pour un cycle de maintenance, les phases d'etudes d'opportunite et d'elaboration 
sont considerablement reduites. L'emploi d'outils de generation de code ou de 
construction d' application peut fortement reduire la phase de construction ; dans 
certains cas elle peut etre plus courte que les phases d'etude d'opportunite et 
d'elaboration mises bout a bout. 



Points de recouvrement des phases et points de decision 

La fin de chaque phase est marquee par une decision planifiee qui correspond a 
de grandes decisions dans la conduite des affaires de l'entreprise. Pendant la 
phase d'etude d'opportunite, la viabilite economique et la faisabilite technique du 
produit sont etablies. A la fin de l'etude d'opportunite, la decision d'allouer ou 
non des ressources pour l'elaboration doit etre prise. A la fin de l'elaboration, un 
point de decision similaire est atteint. En fonction du travail d' architecture deja 
realise et en fonction de 1'evaluation des risques subsistants, il faut allouer ou 
non les ressources pour terminer le produit. 

La construction s'acheve lorsque le produit est suffisamment mur pour que des 
utilisateurs puissent s'en servir de maniere fiable. 

La transition se termine soit lorsque le produit est remplace par une nouvelle 
generation, soit lorsque le produit arrive en fin de vie et n'est plus utilise. 

Parallelement au deroulement des phases, la fin de chaque iteration apporte un 
eclairage sur les progres techniques et la maturite du projet. L' evaluation des 
iterations determine l'etendue des progres et, dans la foulee, entraine les 
reevaluations du cout global, de la planification et du contenu du projet. 
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Le tableau suivant resume les objectifs et les points de decisions rapportes aux 
iterations de la vue technique et aux phases de la vue de l'encadrement. 
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Figure 386 : Tableau recapitulatifd.es objectifs et des points de decisions rapportes aux 

iterations et aux phases. 
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Le tableau suivant recapitule les etapes, les points de mesure et les resultats de 
chaque phase. 



Phase 


Etape 


Mesure 


Resultat 


Etude 
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d'utilisation 

Modele du domaine 
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Stabilite 
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80 % des scenarios 

80 % du modele du 
domaine 
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Plan de deploiement 


Completude des 
livraisons 

Taux de defauts 

Densite de defauts 

Stabilite 


Produit complet 

Documentation 
complete 

Qualite satisfaisante 


Transition 


Versions beta 


Satisfaction des 
utilisateurs 

Taux de defauts 

Densite de defauts 

Stabilite 


Version definitive 



Figure 387 : Tableau recapitulatif des etapes, des points de mesure des resultats de chaque 

phase. 
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Etude de cas : 
application de controle 
d'acces a un batiment 



Ce chapitre presente l'utilisation d'UML pour la modelisation objet d'un systeme 
de controle des acces a un batiment. 

L'etude de cas decrite dans ce paragraphe est inspiree d'une application 
deployee a l'ESSAIM (Ecole Superieure des Sciences Appliquees pour 
l'lngenieur - Mulhouse). 

Le modele de cet exemple - realise avec l'outil Rational Rose - est disponible sur 
le CD-ROM qui accompagne l'ouvrage. 



Le processus 



L'etude de cas debute directement par l'analyse des besoins. Les besoins du 
systeme sont determines a partir de l'information recueillie durant l'interview du 
superviseur du futur systeme. Ces besoins sont exprimes sous la forme de cas 
d' utilisation, dans un langage tres proche des utilisateurs. 

L'etude des cas d'utilisation demande de choisir le niveau de granularite des 
informations representees dans les interactions ; ce qui pose souvent le probleme 
du petit rocher ou du gros caillou. Dans l'exemple suivant, les cas d'utilisation 
sont deliberement consideres comme des elements a forte granularite. 
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Chaque cas d'utilisation regroupe plusieurs scenarios decrits d'abord de maniere 
generale, du point de vue de l'acteur, puis represented de maniere plus 
informatique afin de permettre une evaluation des couts de realisation de 
1' application. 

La structure statique - exprimee par les relations entre les classes des objets qui 
participent aux collaborations - est representee dans des ebauches de 
diagrammes de classes, puis finalisee dans un diagramme de classes qui 
represente les abstractions cles du domaine et leurs relations. 

L'analyse de l'existant etudie les caracteristiques des lecteurs de badges mis en 
oeuvre et permet de degager une strategie pour la realisation des cas d'utilisation. 

L'exemple se termine par la description de 1' architecture logicielle et materielle de 
1' application. 



Analyse des besoins 



Les espaces a proteger se repartissent sur 4 niveaux au sein d'un batiment d'une 
surface totale d' environ 5 000 m 2 . Le batiment est divise en cinq zones : deux ailes 
de recherche, une aile de travaux pratiques, une aile pour 1' administration et un 
corps central qui abrite les salles de cours et les deux amphitheatres. 

Le site accueille environ 500 personnes tous les jours, en majorite des etudiants, 
mais aussi des enseignants, des chercheurs, du personnel administratif et 
technique, ainsi que de nombreux visiteurs. 

Suite a la disparition d'objets divers, il a ete decide de restreindre les acces a 
certaines salles au moyen de portes a fermeture automatique. L'ouverture de 
chacune de ces portes est commandee par un lecteur de badges place a proximite. 

Les badges qui permettent l'ouverture des portes ne sont delivres qu'aux 
personnes qui doivent acceder aux locaux proteges dans l'exercice de leurs 
activites. Les droits d'acces sont alloues entre les groupes de personnes et les 
groupes de portes, de sorte qu'une personne ou une porte doit toujours etre au 
moins dans un groupe (le sien). 

Un groupe de portes peut contenir des portes dispersees dans tout le batiment. 
Du point de vue du controle d'acces, seule la notion de groupe de portes est 
importante : les chemins et les deplacements ne sont pas controles. Une porte 
donnee ne peut appartenir qu'a un seul groupe de portes. 

Une meme personne peut appartenir a plusieurs groupes, de sorte que ses droits 
d'acces correspondent a l'union des droits d'acces de chacun des groupes qui la 
contiennent. 
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La definition des droits d'acces est effectuee en decrivant pour chaque groupe de 
personnes les differents groupes de portes qui sont accessibles et sous quelles 
contraintes horaires. Les droits d'acces sont decrits dans un calendrier annuel qui 
decrit la situation semaine par semaine. Etant donne la faible variation des droits 
dans le temps, un calendrier peut etre initialise au moyen de semaines types qui 
decrivent une configuration de droits donnee. Le superviseur peut creer autant de 
semaines types qu'il le desire. Les changements apportes a une semaine type 
sont automatiquement propages dans tous les calendriers qui utilisent cette 
semaine type. Les changements apportes directement dans un calendrier, par 
exemple pour prendre en compte un jour ferie, ne sont pas affectes lors de la 
modification d'une semaine type. 

La figure suivante represente une semaine type. Les parties en grise 
correspondent aux plages horaires pendant lesquelles l'acces n'est pas autorise. 
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Figure 388 : Exemple de semaine type. 



Le systeme de controle d'acces doit fonctionner de la maniere la plus autonome 
possible. Un superviseur est responsable de la configuration initiale et de la mise 
a jour des differentes informations de definition des groupes de personnes et de 
portes. Un gardien dispose d'un ecran de controle et est informe des tentatives 
de passage infructueuses. Les alarmes sont transmises en temps legerement 
differe : la mise a jour de l'information sur l'ecran de controle est effectuee toutes 
les minutes. 

L'interface utilisateur doit aider l'utilisateur a formuler des requetes correctes. Les 
valeurs de parametres doivent systematiquement etre lues dans des listes qui 
definissent le domaine des valeurs correctes. 
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Description des cas d'utilisation 



Les cas d'utilisation sont decrits de maniere textuelle, agrementee de quelques 
diagrammes d'interaction. A ce stade de la modelisation, les interactions 
represented les principaux evenements qui se produisent dans le domaine de 
1' application. Plus tard, lors de la conception, ces evenements sont traduits en 
messages qui declenchent des operations. 

Determination des cas d'utilisation 

L' analyse debute par la recherche des acteurs (categories d'utilisateurs) du 
systeme de gestion des acces. Un acteur represente un role joue par une 
personne ou par une chose qui interagit avec le systeme. II n'est pas toujours 
facile de determiner la limite du systeme. Par definition, les acteurs sont a 
l'exterieur du systeme. 

Les acteurs se recrutent parmi les utilisateurs du systeme et aussi parmi les 
responsables de sa configuration et de sa maintenance. lis se repartissent dans 
les categories suivantes : 

• superviseur, 

• gardien, 

• porteur de badge. 
Voici leur representation graphique : 

Superviseur 

Gardien 



Figure 389 : Representation des categories d'utilisateurs. 

Les acteurs interagissent avec le systeme. L' etude des cas d'utilisation a pour 
objectif de determiner ce que chaque acteur attend du systeme. La determination 
des besoins est basee sur la representation de l'interaction entre 1' acteur et le 
systeme. Cette approche presente l'avantage de forcer l'utilisateur a definir 
precisement ce qu'il attend du systeme. 




Porteur de 
badge 
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Un cas d'utilisation est une abstraction d'une partie du comportement du 
systeme. Le cas d'utilisation est instancie a chaque utilisation du systeme par une 
instance d'un acteur. 

Apres interview des utilisateurs, il ressort que les categories de besoins 
fonctionnels des acteurs se decomposent de la maniere suivante : 



Acteur 


Cas d'utilisation 


Superviseur 


Configuration du systeme 


Gardien 


Exploitation du systeme 


Utilisateur 


Validation d'une demande d'acces 



Figure 390 : Recapitulatif des cas d'utUisation du systeme de controle d'acces. 

Le diagramme suivant represente les cas d'utilisation du systeme de controle 
d'acces. 



Porteur de badge 




Figure 391 : Diagramme des cas d'utilisation du systeme de controle d'acces. 
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Configuration 

La configuration est declenchee par le superviseur. 

o 

Superviseur Configuration 

Figure 392 : Declenchement de la configuration par le superviseur. 



Identification 

Le superviseur se connecte au systeme et donne son mot de passe. 
Le systeme verifie l'identite du superviseur et autorise la connexion. 



: Superviseur 



Login (mot de passe) 



Autorisatio 



: Systeme 



I 

->| 

Verification 



Figure 393 : Identification du superviseur. 
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Modification des portes 

Le superviseur demande la liste des portes ou des groupes de portes. 

Le systeme affiche la liste des portes ou des groupes de portes. 

Le superviseur choisit une porte ou un groupe de portes. 

Le systeme affiche les informations suivantes : 
l'etat (active / desactive), 
la duree de la temporisation d'ouverture, 
la confidentialite (un seul dedans, les autres dehors). 

Le superviseur modifie les informations precedentes. 

Le systeme enregistre les informations. 



: Superviseur 



: Systeme 



Liste des portes 
K ! 



Choix d'une porte 

>! 

Informations de la porte 

K ! 



Modification d'une porte 




Modification des informations 



Information de la porte 
>\ 



Sauvegarde des info rmations 

I 
I 
I 
I 



Figure 394 : Modification des portes. 
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Modification d'une personne 

Le superviseur demande la liste des personnes. 

Le systeme affiche toutes les personnes deja recensees. 

Le superviseur choisit une personne. 

Le systeme affiche les informations suivantes : 

le nom de la personne, 

le prenom de la personne, 

le numero de telephone de la personne, 

le numero de son badge, 

la liste des groupes auxquels appartient la personne. 
Le superviseur modifie les informations precedentes. 
Le systeme enregistre les informations. 



: Superviseur 



: Svsteme 



Modification des informations 



Modification d'une personne 



Liste des personnes 



Choix d'une personne 



Informations de la personne 



Informations de la personne 



Sauvegarde des informations 



Figure 395 : Modification des personnes. 
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Modification des groupes de personnes 

Le superviseur demande la liste des groupes de personnes. 
Le systeme affiche tous les groupes de personnes deja recenses. 
Le superviseur choisit un groupe de personnes. 
Le systeme affiche les informations suivantes : 

le nom du groupe, 

la liste des membres du groupe, 

la liste des acces possibles pour le groupe. 
Le superviseur modifie les informations precedentes. 
Le systeme enregistre les informations. 




: Svsteme 



: Superviseur 



Modification d'un groupe dej 



personne 



Liste des groupes 



)< 

Choix d'un groupe 



Informations du groupe 



M odification des informations 



KS ' 

Informations du groupe 



Sauvegarde des info) 




Figure 396 : Modification des groupes de 



personnes. 



298 - Modelisation objet avec UML 



Modification des groupes de portes 

Le superviseur demande la liste des groupes de portes. 
Le systeme affiche tous les groupes de portes deja recenses. 
Le superviseur choisit un groupe de portes. 
Le systeme affiche les informations suivantes : 
le nom du groupe, 

la liste des portes contenues par le groupe, 

la liste des acces alloues a des groupes de personnes. 

Le superviseur modifie les informations precedentes. 

Le systeme enregistre les informations. 



: Superviseur 



: Systeme 



Informations du groupe I 

K ! 



Modification des informations 



Modification d'un groupe depones 



Liste des groupes 



Choix d'un groupe 



Informations du groupe 



-^1 

Sauvegarde des informations 



Figure 397 : Modification des groupes de portes. 
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Recherche d'une personne en fonction d'un badge 

Le superviseur donne le numero d'identification du badge. 
Le systeme retrouve la personne a qui le badge a ete alloue. 
Le systeme affiche les informations suivantes : 

le nom de la personne, 

le prenom de la personne, 

le numero de telephone de la personne, 

le numero de son badge, 

la liste des groupes auxquels appartient la personne. 



Recherche des portes franchissables par une personne donnee 

Le superviseur demande la liste des personnes. 
Le systeme affiche toutes les personnes deja recensees. 
Le superviseur choisit une personne. 
Le systeme affiche la liste des portes franchissables. 
Le superviseur choisit une porte. 
Le systeme affiche les informations suivantes : 
l'etat (active / desactive), 

la duree de la temporisation d'ouverture, 

la confidentialite (un seul dedans, les autres dehors), 

l'acces alloue a la personne. 




: Systeme 



: Superviseur 



Recherche d'une personne (badge) 



informations de la personne 



Figure 398 : Recherche d'une personne en fonction d'un badge. 
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: Systeme 



: Superviseur 



Recherche portes franchiss_a| 3les (personn 



Liste de portes 



Choix d'une porte 



Informations sur la porte 



Figure 399 : Recherche des portes franchissables par line personne donnee. 

Recherche des groupes qui contiennent une personne donnee 

Le superviseur demande la liste des personnes. 

Le systeme affiche toutes les personnes deja recensees. 

Le superviseur choisit une personne. 

Le systeme affiche la liste des groupes qui contiennent la personne. 



: Superviseur 



: Systeme 



Reche rche des groupes d'une p^rfe onne 



Liste des personnes 



Choix d'une personne 



Liste de groupes 



Figure 400 : Recherche des groupes qui contiennent une personne donnee. 
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Recherche des personnes qui appartiennent a un groupe donne 

Le superviseur demande la liste des groupes de personnes. 
Le systeme affiche tous les groupes deja recenses. 
Le superviseur choisit un groupe. 

Le systeme affiche la liste des personnes contenues par le groupe. 




: Systeme 



Reche rche des membres d'un grcj upe 
Liste des groupes 



Choix d'un groupe 



Liste des membres 



Figure 401 : Recherche des personnes qui appartiennent d un groupe donne. 



Modification des acces d'un groupe de personnes a un groupe de 
portes 

Le superviseur demande la liste des groupes de personnes. 
Le systeme affiche tous les groupes deja recenses. 
Le superviseur choisit un groupe. 
Le systeme affiche les informations suivantes : 
le nom du groupe, 

la liste des personnes appartenant au groupe, 
la liste des acces aux groupes de portes. 
Le superviseur choisit un acces. 
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Le systeme affiche les informations suivantes : 

un calendrier ouvert par defaut sur la semaine courante, 
dans le calendrier, les plages horaires autorisees. 

Le superviseur modifie les informations precedentes. 

Le systeme enregistre les informations. 



: Superviseur 



: Systeme 



Modification des acces i 

I >| 

jJJste des groupes de personr |es 

r ! 

Choix d'un groupe de personr) es 
Informations du groupe de personjnes 

r< 1 

Cho]ix d'un acces a un groupe de pjortes 

i >l 

Informations sur I'acces 
< 1 

Modification des informations 

1 1 I 

I 

Informations sur I'acces 
i >\ 

I 

Sauvegarde des inf ormations 

\Z I 

I 

I 
I 

I I 



Figure 402 : Modification des acces d'un groupe de personnes a un groupe de portes. 
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Modification d'une semaine type 

Le superviseur demande la liste des semaines types. 

Le systeme affiche toutes les semaines types deja recensees. 

Le superviseur choisit une semaine type. 

Le systeme affiche les informations suivantes : 

le nom de la semaine, 

une description textuelle de la semaine, 

les jours de la semaine decoupes en tranches horaires, 

heure par heure la validite ou non de l'acces. 
Le superviseur modifie les informations precedentes. 
Le systeme enregistre les informations. 



Superviseur 



: Systeme 



Modification des informations 



Modification semaine type | 



Liste des semaines types 



Choix d'une semaine type 



Informations sur la semaine type 



Informations sur la semaine (type 



Sauvegarde des informations 



Figure 403 : Modification d'une semaine type. 



304 - Modelisation objet avec UML 



Recherche des droits d'acces d'une personne pour une porte 
donnee 

Le superviseur demande la liste des personnes et des portes. 
Le sy steme affiche toutes les personnes et portes deja recensees. 
Le superviseur choisit une personne et une porte 
Le systeme affiche les informations suivantes : 

un calendrier ouvert par defaut sur la semaine courante, 

dans le calendrier, les plages horaires autorisees. 



: Superviseur 



: Systeme 



Recharche acces a une porte (UnePersonne 





Liste des portes 






Choix porte 






Liste des personnes 






Choix personne 






Informations sur I'acces 







Figure 404 : Recherche des droits d'acces d'une personne pour une porte donnee. 



Surveillance 

La surveillance est declenchee par le gardien. 
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Gardien 



Figure 405 : Declenchement de la surveUltmce par le gardien. 

Identification 

Le gardien se connecte au systeme et donne son mot de passe. 
Le systeme verifie l'identite du gardien et autorise la connexion. 



: Gardien 



: Systeme 





Login (mot de passe) 










-> 
Veri 


ication 
< 1 




Autorisation 











Figure 406 : Identification du gardien. 

Rapport des evenements 

Le gardien specifie les dates de debut et de fin de la periode desiree. 
Tant que le gardien a envie 

Le systeme affiche les evenements dans l'ordre chronologique. 

Le gardien selectionne des filtres d'affichage. 
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: Gardien 



: Svsteme 



Loop 
End loop 



Rapport evenements (Pqn< })de) 



Evenements 



Figure 407 : Rapport des evenements. 
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Purge des evenements 

Le gardien specifie les dates de debut et de fin de la periode a purger. 
Le systeme detruit les evenements qui correspondent a la periode. 



: Gardien 



: Systeme 



Purge (Periode) 



Destruction des eveitiements 



Figure 408 : Purge des evenements. 

Rapport des alarmes 

Le gardien specifie le delai de rafraichissement (1..60 minutes). 
Jusqu'a ce que le gardien interrompe la detection 

Le systeme affiche regulierement les nouvelles alarmes. 



: Systeme 



: Superviseur 



I 



Loop 

Delay Periode 
End loop 



Rapport alarmes (Periode) 
, ^ 

Liste des alarmes 
k-r 1 



Figure 409 : Rapport des alarmes. 
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Ouverture manuelle des portes 

Le gardien demande la liste des portes. 
Le systeme affiche la liste des portes. 
Le gardien choisit une porte. 
Le systeme affiche les informations suivantes : 
l'etat (active / desactive), 

la valeur de la confidentialite (une personne est-elle dans la salle ?), 

les dix derniers evenements. 
Le gardien force 1' ouverture de la porte. 
Le systeme enregistre l'evenement. 



: Gardien ^Systeme 



Ouverture manuelle des pop es 

i ^1 
Liste des portes 

"I 



K : 1 



Choix d'une porte 

1 >> 

Informations sur la porte 

< 1 

I I 
I Ouverture de la porte 
i >i 

Enregistrement de l'evenement 

I I 1 

I I 
I I 



Figure 410 : Ouverture manuelle des portes. 
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Incendie 

Le gardien declenche l'alarme incendie. 
Le systeme ouvre toutes les portes. 



: Gardien 



: Svsteme 



Incendie 



Ouverture de toutes 16s portes 



Figure 411 :Alarme incendie. 



Controle d'acces 

Le controle d'acces est declenche par le porteur de badge. 




Controle d'acces Porteur de badge 



Figure 412 : Declenchement du controle d'acces par le porteur de badge. 
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Autorisation de passage 

La personne presente son badge. 

Le systeme determine si l'acces est autorise. 

Si l'acces est autorise 

Le systeme commande l'ouverture de la porte. 



Porteur de 



badge 



: Systeme 



If Droits corrects 



End if 



Presente son badge 



->i 



Verifie les droits d'acces 



I 



Ouvre la porte 



Figure 413 : Autorisation de passage. 



Tableau recapitulatif des cas d'utilisation et des scenarios 
principaux 



Cas d'utilisation 


Scenarios principaux 


Configuration 


Identification 


Configuration 


Modification des portes 


Configuration 


Modification des personnes 


Configuration 


Modification des groupes de personnes 


Configuration 


Modification des groupes de portes 


Configuration 


Recherche d'une personne en fonction d'un badge 
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Cas d'utilisation 


Scenarios principaux 


Configuration 


Recherche des portes franchissables par une personne donnee 


Configuration 


Recherche des groupes qui contiennent une personne donnee 


Configuration 


Recherche des personnes qui appartiennent a un groupe donne 


Configuration 


Modification des acces d'un groupe de personnes a un groupe de 
portes 


Configuration 


Modification d'une semaine type 


Configuration 


Affichage des droits d'acces d'une personne pour une porte donnee 


Surveillance 


Identification 


Surveillance 


Rapport des evenements 


Surveillance 


Purge des evenements 


Surveillance 


Detection des alarmes 


Surveillance 


Ouverture manuelle des portes 


Surveillance 


Incendie 


Controle 
d'acces 


Autorisation de passage 



Controles de coherence 

Les contraintes suivantes doivent etre prise en compte par le systeme : 

• chaque lecteur de badges est identifie par une adresse unique, 

• un lecteur de badges ne peut etre associe qu'a une seule porte, 

• une porte doit toujours etre au moins dans son propre groupe, 

• une personne doit toujours etre au moins dans son propre groupe, 

• un badge ne peut etre alloue qu'a une seule personne, 

• les plages horaires definies dans une journee ne doivent pas se chevaucher. 
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Description des collaborations 



Les fonctionnalites decrites par les cas d'utilisation sont realisees par des 
collaborations d'objets du domaine. 



Cas d' utilisation 



Collaboration 



Reali5e>> 



<<Participe» 



= Participe> 



Objet 




i 

Objet 




Objet 



Figure 414 : Realisation d'un cas d'utilisation par une collaboration entre objets du 

domaine. 



La realisation des collaborations fait intervenir des objets supplementaires qui 
n'appartiennent pas au domaine de 1' application mais qui sont necessaires a son 
fonctionnement. Ces objets effectuent generalement l'interface entre le systeme et 
l'utilisateur, ou entre le systeme et un autre systeme. La representation de ces 
objets permet d'evaluer le cout de 1' application ; il est par exemple frequent de 
compter une journee de travail pour la realisation d'un ecran et des mecanismes 
associes. 

La nature particuliere des classes de ces objets peut etre signifiee au moyen des 
stereotypes suivants : 

• «controleur» pour le pilotage et l'ordonnancement, 

• «dispositif» pour la manipulation du materiel, 

• «interface» pour la traduction d'information a la frontiere entre deux 
systemes, 

• «substitut» pour la manipulation d'objets externes au systeme, 

• «vue» pour la representation des objets du domaine. 

Tres souvent, il existe trois elements du modele qui correspondent au meme 
element du monde physique. Cette distinction est en particulier operee dans le 
cas des personnes, parl'intermediaire : 

• des acteurs qui represented les utilisateurs d'un systeme, vu de l'exterieur, 

• des objets, instances de classes issues de 1' analyse du domaine (egalement 
appeles objets metiers) qui encapsulent les informations decrivant chaque 
utilisateur, 
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• des objets d' interface qui permettent de manipuler, lire et modifier les 
informations contenues par les objets de la categorie precedente. 

Le diagramme suivant represente cette trilogie de classes d'objets. L'utilisateur 
est montre sous la forme d'un acteur afin de representer une personne (un 
humain) qui interagit avec le systeme. Les informations sur cette personne sont 
stockees par un substitut et visualisees par un objet d'une classe d'interface (dit 
objet miroir) dont le nom est prefixe par la lettre I. Un meme objet d'interface peut 
visualiser successivement les caracteristiques de differentes personnes. 




Utilisateur 

■1 



Systeme 



/ 



«Vue» 
l_Personne 




«Substitut» 
Personne 


1 



Figure 415 : Differentes categories de classes d'objets. 

Dans un systeme d' information, les informations qui font foi sont celles 
contenues dans le systeme. Dans un systeme automatise, la verite est toujours a 
l'exterieur du systeme. Dans les deux cas, il importe de bien synchroniser l'etat de 
la trilogie d'objets. 

Les acteurs n'interviennent plus directement dans les collaborations. 
L'interaction avec les utilisateurs est exprimee sous la forme de messages 
envoyes et recus par les objets d'interface. Le niveau de granularite de ces objets 
est variable, mais en regie generale les mecanismes representes en termes d'objets 
collaborants evitent d'aller trop loin dans les details de la realisation de l'interface 
utilisateur. II y a deux raisons a cela : d'une part, faciliter la lecture des 
diagrammes, et d' autre part, favoriser la reutilisation des objets metiers. 
L'interface est toujours tres dependante de chaque application. En revanche, les 
objets metiers peuvent souvent etre reutilises par d'autres applications. 

Configuration 
Identification du superviseur 

Dans un premier temps, 1' acteur peut etre conserve pour representer de maniere 
compacte l'interface utilisateur. 
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2: LireMotDePasse 
1 : LireNom 



: Superviseur 




Figure 416 : Representation d'une collaboration entre des objets du domaine et un acteur. 

De maniere alternative, il est egalement possible de creer une classe 
LimiteDuSysteme et de l'employer en lieu et place de l'acteur. 



: LimiteDuSvsteme 



2: LireMotDePasse 
1 : LireNom 




3: Verifier (MotDePasse) A* 



Superviseur : Personne 



Figure 417 : Representation globale de V interface utilisateur au moyen d'un objet de classe 

Limi t eDuSysteme. 

Par la suite, les grandes lignes de l'interface utilisateur peuvent etre decrites au 
moyen de classes qui representent les differentes fenetres. Dans ce cas, le but 
n'est pas de decrire de maniere precise les classes graphiques de l'interface, mais 
plutot de capturer la forme generale des interactions et ainsi de quantifier la 
charge de travail pour le developpement de l'interface. La fabrication de 
l'interface proprement dite est du ressort d'outils specialises dans la construction 
et la generation automatique des interfaces graphiques. 

Par convention, chaque objet du domaine est visualise par un objet d'interface de 
meme nom, prefixe par la lettre F. Dans le diagramme suivant, l'objet de classe 
Login est accessible par l'intermediaire d'un objet graphique F_Login. 
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: F Login 




4: Cacher ( ) 
2: Lire (Norn, MotDe Passe) 
: Afficher ( ) 



: Login 



: F Configuration 




5: Afficher ( ) \\ 

3: Correct ? ( MotDePasse) 



Superviseur : Personne 



Figure 418 : Realisation de la connexion au systeme par une collaboration entre objets. 

Le diagramme de collaboration ci-dessus montre des objets instances de quatre 
classes differentes, divisees en deux classes d'objets du domaine et en deux 
classes d'interface utilisateur. 

Un diagramme de classes preliminaire, compatible avec la collaboration 
precedente, est represente ci-dessous. Etant donne l'etat peu avance de la 
modelisation, les informations de multiplicite ne sont pas toutes determinees a ce 
stade. 



Le comportement des objets de la classe Login peut etre decrit de maniere 
generale par l'automate suivant. L'automate montre, entre autres, que le systeme 
ne precise pas l'origine precise du rejet d'une connexion. 




Figure 419 : Ebauche du diagramme de classes. 
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Login 



Lecture nom 



entry: Invite nom 



Nor i lu 
V 



/■ ^ 

Lecture mot de passe 



entry: Invite mot de pass( 



Mot de Dasse lu 
V 



Verification 



Nom et mot 



Nom ou 
mo de 
passe 

incc rrect 



de passe OK 



Connexion 



Figure 420 : Description generate du comportement des objets de la classe Login. 

Les classes d'interface utilisateur derivent toutes les deux d'une classe 
Fenetre qui definit les operations Afficher() et Cacher () . 



Fenetre 

Afficher( ) 
Cacher( ) 



5 











F_Login 




F_Configuration 



Figure 421 : Hierarchie des classes d'interface utilisateur. 



Modification des portes 

Le superviseur peut modifier les portes de maniere individuelle ou par groupe de 
portes. Les deux scenarios suivants correspondent respectivement a ces deux 
options. 
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1 : Modifier les informations 




: Superviseur 



Figure 422 : Modification des informations des portes par le superviseur. 



Scenario pour une seule porte 

Le diagramme de collaboration suivant represents la modification des 
informations d'une porte. 



: F Configuration 



4: Afficher (Porte selectionnee) 




1 : Afficher ( ) 

2: Selection ( ) 5: Image I 
3:Cacher() 6: Valeur i ) \ 



: L Portes 



: Porte 



Figure 423 : Modification des informations d'une porte. 



Les operations Image () et Valeur () symbolisent la lecture et l'ecriture de 
l'etat de l'objet Porte a partir de l'interface utilisateur. L'operation Image () 
permet a un objet d'interface d'extraire les informations contenues par un objet du 
domaine afin de les montrer aux utilisateurs. Inversement, l'operation Valeur () 
permet a un objet d'interface de transferer des informations en provenance d'un 
utilisateur vers un objet du domaine. 

Ces operations sont heritees de la classe abstraite ObjetDuDomalne. 



ObjetDuDomaine 
Imaqe () 
Valeur () 

' A 



Porte 



Figure 424 : La classe abstraite ObjetDuDomaine specifie les operations Image () et 
Valeur () qui permettent la communication avec 1' interface. 
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La figure suivante represente le diagramme de classes preliminaire qui correspond 
au diagramme de collaboration precedent. 



F Configuration 




F_Porte 












L_Portes 


Porte 



Figure 425 : Ebauche du diagramme de classes. 

Les classes dont le nom est prefixe par une lettre L represented des classes 
d'interface utilisateur specialisees dans la representation de listes d'elements. Ces 
classes possedent une operation Selection () qui permet de recuperer 
l'element selectionne par l'utilisateur dans la liste. Les classes de visualisation de 
listes sont egalement des fenetres, comme le montre le diagramme de classe 
suivant : 



Fenetre 

Afficher( 
Cacher( ) 

T 

Liste 
Selection( ) 



I 











LPortes 




L_Personnes 



Figure 426 : Hierarchie des classes de visualisation de listes. 

Scenario pour un groupe de portes 

L'operation de modification des portes peut egalement etre realisee de maniere 
globale pour un ensemble de portes regroupees dans un groupe de portes. 
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F Configuration 



4: Afficher (Porte selectionnee) 



F GroupeDePortes 



1 : Afficher ( ) 

2: Selection ( ) 5: Image I 
3: Cacher ( ) 6: Valeur (\) ' 



: L GroupeDePortes 



: GroupeDePortes 



Figure 427 : Modification d'un groupe de portes. 

Le diagramme de classes precedent est enrichi pour prendre en compte la 
manipulation des groupes de portes. 



L Portes 




F Configuration 







F Porte 



F_GroupeDePortes 



Porte 



GroupeDePortes 



Figure 428 : Ebauche du diagramme de classes. 

Modification des personnes 

1 : Modifier les informations 
X 




: Superviseur 



Figure 429 : Modification des informations d'une personne. 



320 - Modelisation objet avec UML 



Diagramme de collaboration 



4: Afficher (Personne selectionnee) 



: F Configuration 




1 : Afficher i 
2: Selection ( ) 
3:Cacher() J; Jw\ 



: L Personnes 



Personne 



Figure 430 : Diagramme de collaboration. Modification des informations d'une personne. 

Ebauche du diagramme de classes 



F_Configuration 




F Personne 












L_Personnes 


Personne 



Figure 431 : Ebauche du diagramme de classes. 

Modification des groupes de personnes 



1 : Modifier les informations 




: Superviseur 



Grouoe de personnes 



: Personne 



Figure 432 : Modification des groupes de personnes. 
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Diagramme de collaboration 



: F Configuration 






: F GroupeDePersonnes 







1 : Afficher ( ) 
Selection ( ) 
Cacher ( ) 



5: Image ( 
6: Valeur \)\ 



: L GroupeDePersonnes 



: GroupeDePersonnes 



Figure 433 : Diagramme de collaboration. 



Ebauche du diagramme de classes 



F Configuration 




F GroupeDePersonnes 





L Personnes 



GroupeDePersonnes 



Figure 434 : Ebauche du diagramme de classes. 



Modification des groupes de portes 



1 : Modification des informations 



: Superviseur 




Figure 435 : Modification des groupes de portes. 
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Diagramme de collaboration 



: F Configuration 






: F GroupeDePortes 







1: Afficher ( ) 
2: Selection ( ) 5: Image ^)\ 
3:Cacher() 6: Valeur I 



: L GroupeDePortes 



: GroupeDePortes 



Figure 436 : Diagramme de collaboration. 

Ebauche du diagramme de classes 



F_Configuration 



F_GroupeDePortes 



L Portes 



GroupeDePortes 



Figure 437 : Ebauche du diagramme de classes. 



Recherche d'une personne en fonction d'un badge 



1 : Personne ? (Badge) : Groupe de personnes 




: Superviseur 



2: Lire les informations 



Personne — 



Figure 438 : Recherche d'une personne en fonction d'un badge. 
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Diagramme de collaboration 



1: Afficher ( ) 




3: Afficher ( )\^ 



4: Image ( ) 
5: Valeur ( ) 



Figure 439 : Diagramme de collaboration. 



Ebauche du diagramme de classes 



F_Configuration 



F RecherchePersonne 




GroupeDePersonnes 





F Personne 




Personne 







Figure 440 : Ebauche du diagramme de classes. 



324 - Modelisation objet avec UML 



Recherche des portes franchissables par une personne donnee 



1 : Choisir une personne 
> 



Personne 



2: Choisir un groupe de portes r 




: Superviseur 



3: Lire les informations I Porte —I 



Figure 441 : Recherche des portes franchissables par une personne donnee. 



Diagramme de collaboration 



F Configuration 



3: Cacher ( ) 
2: Selection ( ) / 
1 : Afficher ( ) / / 



: L Personnes : L Portes 



8: Afficher ( ' 
> 



F Porte 



l 6^ 



4: Lj^stePortes 

5: Afficher (] 
Selection ( ) 
7: Cacher ( ) 



Is 



9: Image ( ) 
10: Valeur() 



: Porte 



Personne 



: Porte 








: GroupeDePortes 











Figure 442 : Diagramme de collaboration. 
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Ebauche du diagramme de classes 



F Configuration 




F Porte 







L Personnes 




Porte 



Portes 



Personne 



1 



GroupeDePortes 



Figure 443 : Ebauche du diagramme de classes. 



Recherche des groupes qui contiennent une personne donnee 



1 : Choisir une personne 




Superviseur 



2: Lire les informations 



Figure 444 : Recherche des groupes qui contiennent une personne donnee. 
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Diagramme de collaboration 



: F Configuration 



4: GroupeDePersonnes ( ) 
> 

P e rsonn e s ele ct i onne e 



1 : Afficher ( ) 
, 2: Selection ( ) 
» 3: Cacher ( ) 



5: Afficher ( ) 



L GroupeDePersonnes 



L Personnes 



: Personne 





: GroupeDePersonnes 







Figure 445 : Diagramme de collaboration. 



Ebauche du diagramme de classes 





F Configuration 




Personne 








* 



GroupeDePersonnes 



L_Personnes L_GroupeDePersonnes 



Figure 446 : Ebauche du diagramme de classes. 
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Recherche des personnes qui appartiennent a un groupe donne 



1 : Choisir un groupe 




: Superviseur 



2: Lire les informations 



Figure 447 : Recherche des personnes qui appartiennent a un groupe donne. 



Diagramme de collaboration 



: F Configuration 



4: Afficher ( ) 
> 



: L Personnes 



1 : Afficher ( ) 
2: Selection ( ) Groupe>el§ctionne 
i 3: Cacher ( ) 



: L GroupeDePersonnes 



: GroupeDePersonnes 



Figure 448 : Diagramme de collaboration. 
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Ebauche du diagramme de classes 



F Configuration 




L Personnes 







L GroupeDePersonnes 




GroupeDePersonnes 


* 





Figure 449 : Ebauche du diagramme de classes. 



Modification des acces d'un groupe de personnes a un groupe de 
portes 



X 



: Groupe de personnes 



1 : Choisir un groupe 



: Personne 




: Superviseur 



4: Modifier les informations 



: Acces 



: Calendrier 



: Groupe de portes 



Figure 450 : Modification des acces d'un groupe de personnes a un groupe de portes. 
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Diagramme de collaboration 



: F Configuration 



1 : Afficher ( ) 
2: Selection ( ) 
3: Cacher ( ) 



: L GroupeDePersonnes 



4: Afficher ( ) 
5: Acces ( ) 
> 




: F GroupeDePersonnes 



9: Afficher ( ) ■ E Acces 



: GroupeDePersonnes 



F Calendrier 



7: Image ( ) 
8: Valeur ( ' 
> 



Acces 



: GroupeDePersonnes 



10: Image ( ) 
^11: Valeur ( ) 





: Calendrier 







: GroupeDePortes 



Figure 451 : Diagramme de collaboration. 



Ebauche du diagramme de classes 




Figure 452 : Ebauche du diagramme de classes. 
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Modification d'une semaine type 



1 : Lire les informations 




: Superviseur 



Figure 453 : Modification d'une semaine type. 



Diagramme de collaboration 



: F Configuration 



4: Afficher ( ) 
> 



: F SemaineType 



'I 



3: Cacher ( ) 
2: Selection ( ) 
1: Afficher () 



5: Image ( ) 
6: Valeur ( ) 



L SemaineType 



: Semaine type 



Figure 454 : Diagramme de collaboration. 



Ebauche du diagramme de classes 



F_Configuration 



F_SemaineType 



L_SemaineType 



Semaine type 



Figure 455 : Ebauche du diagramme de classes. 
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Recherche des droits d'acces d'une personne pour une porte 
donnee 




Figure 456 : Recherche des droits d'acces d'une personne pour une porte donnee. 

Diagramme de collaboration 

Les liens annotes par un numero entre parentheses ont ete crees par 1' operation 
declenchee par le message de rang correspondant au numero. 
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3: Cacher ( ) 
2: Selection ( 
1 : Afficher ( 



: F Configuration 



L Portes 




4: Afficher ( ) 
^ 5: Selection ( ) 
7: Afjicljier ( \ 6: Cacher ( ) 



: F Calendrier 



: Porte 




L Personnes 



8: Image ( ) 
>L 9: Valeur ( ) 



: Calendrier 



: GroupeDePortes 



Personne 



: Acces 



: GrouoeDePersonnes 



Figure 457 : Diagramme de collaboration. 

Ebauche du diagramme de classes 




Porte 



Caler 


ldrier 




Personne 



1 



GroupePePortes 



Acces 



GroupePePersonnes 



Figure 458 : Ebauche du diagramme de classes. 
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Surveillance 
Identification du gardien 



2: Login (nom, mot de passe) 




1 : Existe ? (nom, mot de passe) 



Figure 459 : Identification du gardien. 



Diagramme de collaboration 



3: Cacher ( ) 
2: Lire (Nom, MotDePasse) 
1 : Afficher ( ) 





4: Afficher ( ) 

5: Correct ? (MotDePasse) 



Gardien : Personne 



Figure 460 : Diagramme de collaboration. 
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Ebauche du diagramme de classes 




Figure 461 : Ebauche du diagramme de classes. 

Rapport des evenements 



1 : Lire les informations : Evenement _ 




: Gardien 

Figure 462 : Rapport des evenements. 

Diagramme de collaboration 



: F Surveillance 


1 : Afficher ( ) 














: L Evenements 



: Evenement 



Figure 463 : Diagramme de collaboration. 
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Ebauche du diagramme de classes 



F Surveillance 




L Evenements 









Evenement 



Figure 464 : Ebauche du diagramme de classes. 



Purge des evenements 




Figure 465 : Purge des evenements. 



Diagramme de sequence 

L'interaction est representee ici au moyen d'un diagramme de sequence qui est 
plus expressif qu'un diagramme de collaboration pour la representation des 
structures de controle. 
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: F Surveillance 



F Purge 



Iterateur 



Tant que pas 



fin 



Afficher ( ; 



Initialiser (Perioj je ) 



Fini ( ) 



Valeur ( ) 



Detruire ( ) 



Suivant ( ) ! 

^1 



Valeur i 



Evenement 



Figure 466 : Diagramme de sequence. 



Ebauche du diagramme de classes 



F Surveillance 



Iterateur 



F_Purge 



Evenement 



Figure 467 : Ebauche du diagramme de classes. 



Rapport des alarmes 



[1 minute] :Lire les information Alarme : Evenement 




: Gardien 



Figure 468 : Rapport des alarmes. 
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Diagramme de collaboration 



: F Confiauration 




: F Alarme 









Afficher ( ) 



: L Evenements 




: Anomalie 



Figure 469 : Diagramme de collaboration. 



Ebauche du diagramme de classes 



F_Configuration 



F Alarme 



L Evenements 



Anomalie 



Figure 470 : Ebauche du diagramme de classes. 



338 - Modelisation objet avec UML 



Ouverture manuelle des portes 




Figure 471 : Ouverture manuelle des portes. 



Diagramme de collaboration 



F Surveillance 



4: Afficher ( ) 
> 



3: Cacher ( ) 
2: Selection ( ) 
1 : Afficher ( ) 



: L Portes 




5: Image ( ) 
6: Ouvrir ( 



Figure 472 : Diagramme de collaboration. 
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Ebauche du diagramme de classes 



F Surveillance 




F Porte 









L Portes 



Porte 



Figure 473 : Ebauche du diagramme de classes. 



Incendie 




Figure 474 : Incendie. 



Diagramme de sequence 



F Surveillance : Porte 



Pour toute les portes 



fin 



Ouvrir ( ) 



Figure 475 : Diagramme de sequence. 
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Ebauche du diagramme de classes 



F_Surveillance 



Porte 



Figure 476 : Ebauche du diagramme de classes. 



Controle d'acces 
Autorisation de passage 

1 : Ouvrir (Badge) 



Portier 




2: Personne ? (Badge) 



Personne 



Porteur de 
badge 



Badge 



Figure 477 : Autorisation de passage. 
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Diagramme de collaboration 



Lecteur de badge 



4: Verifier appartenance'a ia liste d'acces 




1 : AccesValide (Badge) 



Badge 



: Porte 



Personne 



2: Badge (Badge) 
3: ListeAcces ( ) 



: GroupeDePortes 



: Acces 



: GroupeDePersonnes 



Figure 478 : Diagramme de collaboration. 



Ebauche du diagramme de classes 



Lecteur de badge 



Porte 



1 



GroupePePortes 



Acces 



Badge 



Personne 



GroupePePersonnes 



Figure 479 : Ebauche du diagramme de classes. 
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Analyse 



Analyse du domaine 



Les cas d'utilisation segmentent l'espace des besoins selon le point de vue d'un 
acteur a la fois. La description donnee par les cas d'utilisation est purement 
fonctionnelle et il convient de prendre garde a ne pas embrayer vers une 
decomposition fonctionnelle plutot que vers une decomposition objet. Les cas 
d'utilisation doivent etre vus comme des classes de comportement. 

UML realise les cas d'utilisation au moyen de collaborations entre objets issus du 
domaine de l'application. Chaque collaboration regroupe un contexte d'objet et 
une interaction entre ces objets. Le contexte des objets est exprime de maniere 
particuliere dans les diagrammes de collaboration et de maniere generale dans les 
diagrammes de classes. Ces diagrammes de classes ont ete ebauches dans le 
paragraphe precedent. 

Le diagramme de classes suivant est obtenu automatiquement (grace a l'outil 
Rose) a partir de ces differentes ebauches. 



Lecteur de badges 



Adresse 

Anti-retour 

Site 

Temporisation 
Type d'evenements 




Numero de porte 
Numero de salle 



Porte 



Veille 



0..4000 



GroupeDePortes 



Badge 



Validite 

Numero de site 
Numero de badge 



Personne 



GroupeDePersonnes 



Prenom 
Norn 



, Norn 



Figure 480 : Diagramme de classes obtenu par synthese automatique des differentes 

ebauches. 
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L'examen du diagramme precedent fait apparaitre deux associations redondantes 
(entre les classes Personne, Porte et GroupeDePortes) qui peuvent etre 
derivees d'autres associations. Le diagramme suivant fait etat des ajustements 
qui ont ete apportes au modele du domaine. 



Lecteur de badges 



Adresse 

Anti-retour 

Site 

Temporisation 
Type d'evenements 
Veille 



1 



0..4000 



Ba 


dae 


Validite 

Numero de site 
Numero de badge 




1 
1 



Personne 



Prenom 
Norn 



Porte 



Numero de porte 
Numero de salle 



GrouDeC 


ePortes 


Norn 





Ac :es 



GroupeDePersonnes 
Norn 



Calendrier 



"FT 



! Semaine type ] 
! i 



Figure 481 : Diagramme des classes du domaine. 



La classe Acces a ete transformee en association car elle ne contenait pas 
d' informations particulieres. Le detail des droits est exprime dans la classe- 
association Calendrier. La relation de composition represente les semaines 
type qui ont ete modifiees localement dans un calendrier donne. 



Analyse de I'existant 

L'Essaim dispose deja d'un certain nombre de lecteurs de badges et desire les 
reutiliser dans le nouveau systeme de controle d' acces. Ces lecteurs de badges 
peuvent fonctionner de maniere totalement autonome ; ils sont programmables 
sur place au moyen de badges particuliers ou a distance via une liaison serie. 
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Tous les lecteurs sont esclaves du systeme de controle : un lecteur n'est jamais a 
l'origine d'une interaction. 

Caracteristiques des lecteurs de badges 

Chaque lecteur de badges possede les caracteristiques suivantes : 

• la memorisation de 4 000 cartes, avec la possibility d'invalider certaines cartes, 

• la memorisation des 100 derniers evenements (un filtre permet d'enregistrer 
uniquement les anomalies), 

• une adresse sur le reseau (il peut y avoir jusqu'a 64 lecteurs connectes au 
reseau), 

• une horloge logicielle, 

• 8 plages horaires, 

• une temporisation de gache, 

• une fonction anti-retouroptionnelle (entre tete principale et tete auxiliaire), 

• une entree tout-ou-rien connectee au choix a un bouton-poussoir, un contact 
de porte ou une boucle de detection, 

• un etat qui precise si le lecteur est actif ou en veille. 



Horloge 



Plage horaire 



Lecteur de badges 



Adresse 

Anti-retour 

Site 

Temporisation 
Type d'evenements 
Veille 



1 



0..4000 



Badge 



ToutOuRien 



0..100 



Evenement 



Figure 482 : Representation des caracteristiques des lecteurs de badges. 



Mise a l'heure 

Chaque lecteur contient une horloge logicielle. En cas de coupure de courant, le 
lecteur enregistre un evenement special lors de sa remise sous tension et ne gere 
plus les plages horaires. L'horloge doit alors etre remise a l'heure par le systeme 
de controle pour que le lecteur fonctionne a nouveau avec les plages horaires. La 
difference entre l'heure de l'horloge et l'heure reelle donne la duree de la coupure. 
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Horloge 
Jour 
Heure 
Minute 



Figure 483 : Horloge logicielle contenue par les lecteurs de badges. 

Gestion des badges 

Le lecteur peut memoriser jusqu'a 4000 numeros de badge. Ces numeros de badge 
peuvent etre manipules par groupes de numeros croissants. Le lecteur propose 
les operations suivantes : 

• validation d'un badge, 

• validation d'un groupe de badges, 

• invalidation d'un badge, 

• invalidation d'un groupe de badges. 

Plages horaires 

Une plage horaire est associee a chaque badge ou groupe de badges. Un lecteur 
contient la description de 8 plages horaires. Une plage horaire permet de 
restreindre les acces en fonction du jour et de l'heure de presentation du badge. 
Les 7 premieres plages sont configurables par le superviseur, la derniere plage est 
le passe tout temps. Chaque plage horaire comporte 3 sous-plages qui ne doivent 
pas se recouvrir. 

Les plages se presentent de la maniere suivante : 



Sous-plage 


LU 


MA 


ME 


JE 


VE 


SA 


Dl 


00:00-00:00 
















00:00-00:00 
















00:00-00:00 

















Figure 484 : Plage horaire. 



Le diagramme de classes correspondant prend la forme suivante : 
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SousPlage 

Debut 
Fin 

Jour 
1 

Droit 



Figure 485 : Representation des plages horaires. 

Evenements 

Les evenements sont memorises suivant les criteres de parametrage (tous les 
evenements ou seulement les anomalies). Chaque lecteur peut enregistrer au 
maximum 100 evenements entre 2 interrogations provenant du systeme maitre. 
Apres interrogation les evenements sont effaces. La memoire du lecteur est 
organisee sous la forme d'un tampon circulaire. Les plus vieux evenements sont 
effaces en cas de debordement de la memoire. 

Chaque evenement contient les informations suivantes : 

• la date, 

• le numero de badge, 

• la tete concernee (principale ou auxiliaire). 



Evenement 
Date 

Numero de carte 
Tete 



Figure 486 : Description des evenements. 



Le lecteur enregistre les evenements suivants : 

• carte acceptee, 

• coupure secteur, 

• carte refusee lecteur en veille, 

• carte refusee hors plage, 



PlageHoraire 
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• carte refusee mauvais code site, 

• carte refusee carte non programmed, 

• carte refusee defaut anti-retour, 

• carte refusee mauvaise plage horaire. 

Ces types d'evenements sont representes dans le diagramme suivant : 



Evenement 



I 



I 











Anomalie 




Normal 



A 











Coupure secteur 




Carte refusee 



Carte acceptee 



Anti-retour 


Hors plage 


Lecteur en veille 


Mauvais site 


Non programmer 



Figure 487 : Hierarchie des types d'evenements. 



Types de messages 

La communication entre les lecteurs de badges et le systeme maitre est effectuee 
par des messages issus des trois grandes categories suivantes : 

• les messages simples qui contiennent un entete mais pas de donnees, 

• les messages qui contiennent des donnees de longueur fixe, 

• les messages qui contiennent des donnees de longueur variable. 
Ces types de messages sont representes dans le diagramme suivant : 
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Message 

~7T~ 















Simple 




Fixe 




Variable 



Figure 488 : Differentes categories de messages. 

Messages simples 

Les messages simples regroupent des messages de synchronisation, 
requetes de rapport et des commandes. 

Message 
Simple 







— 




Synchronisation 




Requete 




Commande simple 



Figure 489 : Representation des types de messages simples. 

Messages recus par le lecteur : 

• acquittement, 

• non acquittement, 

• requete evenements, 

• requete reglage parametres, 

• requete cartes valides, 

• requete cartes invalides, 

• requete horloge, 

• requete code site, 

• commande mise en veille, 
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• commande sortie du mode veille, 

• commande ouverture porte. 



Synchronisation 



I 











Acquittement 




Non acquittement 



Figure 490 : Representation des types de messages de synchronisation. 



Requete 



z 













Req_Evenements 


Req_Parametres 




ReqJHorloge 










Req_CartesValides 


Req_Cartes 1 n valides 


Req_CodeSite 



Figure 491 : Representation des types de requetes simples. 



Commande simple 



1 
















Cmd_MiseEnVeille 




Cmd_FinVeille 




Cmd_OuverturePorte 



Figure 492 : Representation des types de commandes simples. 
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Messages de longueur fixe 



Message 



Longueur fixe 



1 



Commande fixe 



Rapport fixe 



Figure 493 : Representation des types de messages de longueur fixe. 



Messages recus par le lecteur : 

• commande reglage parametres, 

• commande validation d'une carte, 

• commande validation d'un groupe de cartes, 

• commande invalidation d'une carte, 

• commande invalidation d'un groupe de cartes, 

• commande mise a l'heure, 

• commande transmission d'une plage horaire, 

• commande envoi du code site. 
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Commande fixe 



Cmd_Parametres 
Cmd_ValidationCarte 
Cmd_ValidationGroupe 
CmdJnvalidationCarte 
Cmd_lnvalidationGroupe 

Cmd_Horloge 
Cmd_PlageHoraire 

Cmd_CodeSite 



Figure 494 : Representation des types de commandes fixes. 

Messages envoyes par le lecteur : 

• rapport reglage parametres, 

• rapport horloge, 

• rapport d'une plage horaire du lecteur specifie, 

• rapport code site. 
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Rapport fixe 



Rpt_Parametres 



Rpt_Horloge 



Rpt_PlageHoraire 



Rpt_CodeSite 



Figure 495 : Representation des types de rapports fixes. 



Messages de longueur variable 



Message 



Longueu 


r variable 


/ 




Rapport variable 



Figure 496 : Representation du type messages de longueur variable. 

Messages envoyes par le lecteur : 

• rapport evenement, 

• rapport cartes valides, 

• rapport cartes invalides. 
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Rapport variable 



5 











Rpt_Evenements 


Rpt_CartesValides 


Rpt_Carteslnvalides 



Figure 497 : Representation des types de rapports de longueur variable. 

Structure des trames 

Les messages sont encapsules par des trames qui contiennent des informations 
d'adressage et de verification de la transmission. 

Chaque trame prend la forme suivante : 



Debut 


Adresse 


Check-sum 


Donnees 


Fin 


1 octet 


1 octet 


2 octets 


0..n octets 


2 octets 


01 H 


00H .. 3FH 






F1H-F2H 



Figure 498 : Forme generate des trames de transmission. 



La classe des trames offre les operations Image () et Valeur () pour le 
transfert des trames. L'operation Image () transforme un objet trame en une 
suite d' octets susceptible d'etre transmise via la liaison serie qui relie les lecteurs 
de badges et les PC. Inversement, l'operation Valeur () reconstruit un objet 
trame a partir d'une suite d'octets en provenance d'un des lecteurs de badges. 



Trame 




Debut : Byte : = 01 H 
Adresse : Byte 
Sommel : Byte 
Somme2 : Byte 
Fin1 : Byte : = F1H 
Fin2 : Byte : = F2H 








Donnee 


♦ 

1 


Valeur : Byte 


{Ordonnee} 


lmage( ) 
Valeur( ) 



Figure 499 : Representation de la classe des trames. 
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Le comportement de l'operation Valeur () est decrit par 1' automate suivant : 

Octet lu 



Attente trame ^_ 



Pre : ixe lu 



Attente longueur 



Longueur lue 

I r 



Octet lu[ Cpt < Longueur ] 



Suffi ce lu[ Cpt = Longueur ] 



4 



Figure 500 : Representation du comportement de l'operation Valeur ( ) . 



Architecture 



Architecture logicielle 

Ces lecteurs de badges peuvent etre representes par un acteur. Dans le 
diagramme suivant, le lecteur de badges est represente par une classe stereotypee 
pour insister sur le fait qu'il s'agit d'une classe de dispositifs materiels et non de 
personnes. 



Superviseur 



Lecteur de badge 
«Acteur» 



Gardien 



Porteur de 
badge 



Figure 501 : Representation des acteurs. 
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Le materiel utilise permet de deporter le cas d' utilisation du controle d'acces vers 
les lecteurs de badges. Selon le point de vue retenu, le lecteur de badges se 
comporte comme un acteur pour le systeme de controle d'acces dans son 
ensemble ou comme un systeme independant avec lequel interagit le porteur de 
badge. 



Figure 502 : Le cas d' utilisation du controle des acces est deporte vers les lecteurs de badges. 

Du point de vue global, les lecteurs de badges apparaissent comme un acteur au 
meme titre que le superviseur et le gardien. Le systeme est constitue de deux 
sous-systeme distincts. D'une part le logiciel specifique a developper (pour 
execution sur les PC) et d'autre part le systeme cle en main, livre avec les lecteurs 
de badges. 



Lecteur de badges 




Controle d'acces 



Porteur de badge 





Lecteur de badges 
«Acteur» 



Superviseur 



Configuration 






Identification 



Controle d'acces 



Porteur de badge 




Surveillance 



Gardien 



Figure 503 : Representation definitive des cas d' utilisation. 



La structure de la vue logique prend la forme suivante. Les objets metiers sont 
regroupes dans un paquetage Domaine. Les composants miroirs de ces objets 
du domaine sont contenus dans le paquetage IHM. La couche la plus basse 
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comprend une categorie Persistance qui encapsule une base de donnee, un 
paquetage Machine virtuelle qui isole l'application des particularites du 
materiel et un paquetage Lecteur physique contenant des classes qui 
permettent la manipulation des lecteurs de badges et qui encapsulent toute la 
complexite de la communication. 



IHM 



Domaine 



Persistance 



I 1 

| j 

l Utilitaires 

I 

I 

[global 









Lecteur 
physique 


_i 3 


Machine 
virtuelle 





Figure 504 : Structure de la vue logique. 



Architecture materielle 

Le systeme est constitue d'elements logiciels et materiels, interchangeables dans 
une large mesure. 

Les lecteurs de badges sont interconnectes au moyen d'un reseau specifique, 
independant de 1' Intranet. Le poste de travail du superviseur et la station de 
controle du gardien sont egalement connectes a ce reseau dedie au controle 
d'acces. II peut y avoir jusqu'a 64 lecteurs de badges connectes au reseau. 
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Figure 505 : Architecture materielle. 



Realisation 

Cette etude de cas a pour objectif de presenter la modelisation objet avec UML, 
de sorte que la realisation n'est pas decrite ici en detail. Les grandes etapes de la 
realisation comprennent : 

• la generation automatique du schema de la base de donnees a partir des 
classes du domaine designees comme persistantes, 

• la generation des ecrans par un constructeur d'interfaces graphiques, 

• la realisation manuelle des interactions a partir des diagrammes de 
collaboration. 



Annexes 



Al 

Les elements standard 



Les stereotypes, les etiquettes et les contraintes sont les mecanismes mis a la 
disposition de l'utilisateur pour l'extension d'UML. 



Stereotypes predefinis 



Les stereotypes predefinis par UML sont presentes par ordre alphabetique dans 
le tableau suivant. Les trois colonnes contiennent respectivement le nom du 
stereotype, l'element de modelisation auquel il s'applique et la description 
detaillee de sa semantique. 



Nom 


Sujet 


Semantique 


acteur 


type 


abstraction externe au systeme en cours de 
modelisation 


ami 


dependance 


extension de la visibility d'un paquetage au contenu 
d'un autre paquetage 


appel 


dependance 


operation qui appelle une autre operation 


application 


composant 


composant qui represente un programme executable 


besoin 


note 


note qui exprime un besoin ou une obligation 


bibliotheque 


composant 


composant qui represente une bibliotheque statique 
ou dynamique 


contrainte 


note 


transforme une note en contrainte 


copie 


dependance 


copie profonde d'une instance dans une autre 



362 - Modelisation objet avec UML 



Nom 


bujet 


Semantique 


derivee 


dependance 


la source est derivee de la cible 


devient 


dependance 


transformation des caracteristiques d'une meme 
instance 


document 


composant 


composant qui represente un document 


enumeration 


type primitif 


ensemble d'identificateurs qui torment le domaine de 
valeur d'un type 


envoi 


dependance 


relation de dependance entre une operation et un 
signal envoye par I'operation 


etend 


generalisation 


le cas d'utilisation source etend le comportement du 
cas d'utilisation cible 


facade 


paquetage 


paquetage qui ne fait que referencer des elements 


fichier 


composant 


composant qui represente un fichier source 


flot 


classe active 


classe active qui represente un flot de controle leger 
(thread) 


import 


dependance 


rend la partie publique d'un paquetage visible a un 
autre paquetage 


instance 


dependance 


relation entre une instance et son type 


interface 


type 


vue d'un type 


liaison 


dependance 
collaboration 


relation de dependance entre un type instancie ou 
une collaboration et un type modele ou une 
collaboration modele 


metaclasse 


dependance 
type 


relation de dependance entre un type et sa 
metaclasse 


page 


composant 


composant qui represente une page web 


powertype 


dependance 
type 


relation de dependance entre une generalisation et un 
type dont les instances sont les sous-types qui 
participent a la generalisation 


processus 


classe active 


classe active qui represente un flot de controle lourd 


raffinement 


dependance 


la source derive de la cible et ajoute de I'information 


role 


dependance 


dependance entre un type et un role d'association 


signal 


classe 


classe qui represente un evenement 


souche 


paquetage 


paquetage entierement transfere 


sous-classe 


generalisation 


le sous-type herite de la structure et du comportement 
du super-type, sans etre un type du super-type 


sous-type 


generalisation 


le sous-type herite de la structure et du comportement 
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Norn 


Sujet 


Semantique 






du super-type, et devient un type du super-type 


table 


composant 


composant qui represente une table de base de 
donnees 


trace 


dependance 


relation de dependance entre elements de modeles 
differents 


utilise 


dependance 


le cas d'utilisation source utilise le comportement du 
cas d'utilisation cible 


utilitaire 


type 


type non instanciable qui regroupe des operations et 
des attributs 



Etiquettes predefines 



Les etiquettes predefinies par UML sont presentees par ordre alphabetique dans 
le tableau suivant. Les quatre colonnes contiennent respectivement le nom de 
l'etiquette, le domaine de definition de sa valeur, l'element de modelisation auquel 
elle s' applique et la description detaillee de sa semantique. 



Nom 


Valeur 


Sujet 


Semantique 


documentation 


chaTne 


SISment 


commentaire, description ou 
explication 


invariant 


non interprets 


type 


prSdicat qui doit etre toujours vrai 
pour toutes les instances du type 


localisation 


composant 


SISment de 
modelisation 


assignation de la rSalisation d'un 
SISment de modSlisation dans un 
composant 




noeud 


composant 


assignation d'un composant sur 
un noeud 


persistance 


enumeration 

{transitoire, 
persistant} 


type 

instance 

attribut 


permanence de I'Stat 


post-condition 


non interprets 


opSration 


prSdicat qui doit etre vrai apres 
invocation d'une opSration 


pre-condition 


non interprets 


opSration 


prSdicat qui doit etre vrai avant 
invocation d'une opSration 


responsabilite 


chaTne 


type 


obligation liSe a un type 


semantique 


non interprets 


type 


spScification de la sSmantique 
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operation 




semantique 
spatiale 


non interprets 


type 

operation 


specification de la complexite 
spatiale 


semantique 
temporelle 


non interprets 


type 

operation 


specification de la complexite 
temporelle 
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Contraintes predefines 



Les contraintes predefinies par UML sont presentees par ordre alphabetique dans 
le tableau suivant. Les trois colonnes contiennent respectivement le nom de la 
contrainte, l'element de modelisation auquel elle s'applique et la description 
detaillee de sa semantique. 



Nom 


Sujet 


Semantique 


association 


role de lien 


I'instance correspondante est visible par une 
association 


chevauchement 
inclusif 


generalisation 


les instances peuvent avoir plusieurs types parmi 
les sous-types 


complete 


generalisation 


tous les sous-types ont ete specifies 


diffusion 


message 


I'ordre d'invocation des messages n'est pas 
specifie 


disjointe 
exclusif 


generalisation 


les instances n'ont qu'un seul type parmi les 
sous-types 


global 


role de lien 


I'instance correspondante est visible, car placee 
dans une portee globale 


implicite 


association 


I'association n'est pas manifeste, mais 
conceptuelle 


incomplete 


generalisation 


tous les sous-types n'ont pas ete specifies 


local 


role de lien 


I'instance correspondante est visible, car elle est 
une variable locale d'une operation 


ordonnee 


role d'association 


la collection, representee par I'association, est 
ordonnee 


ou 


association 


associations mutuellement exclusives 


parametre 


role de lien 


I'instance correspondante est visible, car elle est 
parametre d'une operation 


self 


role de lien 


I'instance correspondante est visible car elle 
participe a la distribution du message 


vote 


collection de 
messages 


la valeur de retour est choisie par vote majoritaire 
parmi les valeurs retournees par la collection de 
messages 



A2 



Guide de transition de 
Booch et OMT vers UML 



Ce guide a pour objectif de faciliter la transition des utilisateurs des notations de 
Booch'93 ou OMT-2 vers la notation UML. 

Les notations de Booch, OMT et UML fournissent trois vues differentes de 
concepts objet tres proches. En fait, les notations de Booch et OMT pourraient 
etre utilisees pour representer une grande partie des elements de modelisation 
definis dans le metamodele d'UML. 

Graphiquement, UML est plus proche d'OMT que de Booch, car les icones en 
forme de nuage ont ete abandonnees au profit de rectangles plus faciles a 
dessiner. Au-dela des aspects graphiques, UML peut etre consideree comme un 
sur-ensemble des deux autres notations. 



Les tableaux qui suivent illustrent les differences de notations concernant les 
principaux concepts objet. 




Figure 506 : UML est un sur-ensemble de Booch et OMT. 
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Les mecanismes de base 



Contmintes 

Dans les trois notations, les contraintes se representent par des expressions entre 
accolades. 



Booch 


OMT 


UML 


Texte entre accolades 
{Ceci est une contrainte} 


Texte entre accolades 
{Ceci est une contrainte} 


Texte entre accolades 
{Ceci est une contrainte} 



Notes 

En Booch et en UML, les notes se representent par des rectangles, avec un coin 
replie. En OMT, les notes se representent comme les contraintes. 

En Booch le coin bas-gauche est replie, alors qu'en UML, le coin haut-droit est 
replie. 



Booch 


OMT 


UML 




Ceci est 
une note 




texte entre accolades 
{Ceci est une note} 




Ceci est k 
une note 





Categories 

En Booch et en OMT, les categories font partie des elements de modelisation. En 
UML, les categories se realisent par stereotypage des paquetages. 



Booch 


OMT 


UML 




Categorie 




j Categorie | 

i j 
i 

i_ i 


«Cateqorie» 
i i 
I Paauetaae I 










L 1 



Sous-systemes 

En Booch et en OMT, les sous-systemes font partie des elements de 
modelisation. En UML, les sous-systemes se realisent par stereotypage des 
paquetages. 
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Booch 


OMT 


UML 




Sous-systeme 






Sous-systeme 




1 1 

«Sous-systeme» 
| Paquetage | 



Les objets 

En Booch, les objets se represented par des nuages. En OMT, comme en UML, 
les objets se represented par des rectangles. En UML, le nom des objets est 
souligne. 



Booch 


OMT 


UML 








/ Nom : y 
Classe ( 


Nom : Classe 


Nom : Classe 







Les liens 



Dans les trois notations, les liens se represented par une ligne continue, tracee 
entre les objets. 



Booch 



OMT 



UML 





: A 




: B 









: B 


: A 





Specification de realisation 

Booch et UML permettent de preciser la construction retenue pour la realisation 
d'un lien, au moyen d'un petit carre place sur le role. Le symbole place dans le 
carre indique la nature du lien. Un carre noir indique une realisation par valeur, un 
carre blanc indique une realisation par reference. 



OMT ne propose pas d'attribut graphique particulier, en dehors des contraintes. 
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Booch 


OMT 


UML 


C 




) 

I 






— 0 






c 






— * 


F membre {field) 

G global 

L local 

P parametre 




A association 

F membre {field) 

G global 

L local 

P parametre 

Sself 



Les messages 



Dans les trois notations, les messages se represented au moyen de fleches 
placees a proximite des liens. 

La forme de synchronisation de l'envoi de message est symbolisee par une forme 
de fleche particuliere. 



Booch 



OMT 



UML 










Stereotypage pour les 
autres formes de 
synchronisation 
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Ordre d 'envoi 

L'ordre d'envoi est represents dans les trois notations par une expression placee 
en tete du message. 



Booch 


OMT 


UML 


Notation decimale 


Notation decimale pointee 


Notation decimale pointee 
modifiee 

caractere flot 

chiffre etape dans un 
flot 

* iteration 



Flots de donnees 

Booch et UML permettent de representer les flots de donnees parallelement aux 
flots de controle (les messages), au moyen de petits cercles accoles a une fleche 
dirigee dans le sens du flot de donnees. Cette notation est optionnelle, car 
redondante avec la representation des parametres des messages. 



Booch 


OMT 


UML 




Par les parametres des 
messages 


- — > 




1 1 1 







Les classes 



En Booch, les classes se representent par des nuages pointilles. En OMT, comme 
en UML, les classes se representent par des rectangles. 

Classe simple 



Booch 


OMT 


UML 








/ Une ^ 
C classe f 


Une classe 


Une classe 
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Attributs et operations 

Dans les trois notations, les attributs et les operations sont represented au sein 
de l'icone de la classe. Certains attributs et certaines operations peuvent etre 
masques pour ne pas surcharger les diagrammes. 

OMT et UML proposent des compartiments pour distinguer les attributs des 
operations. 



Booch 


OMT 


UML 








/ Une classe J 

(. Attribut ( 
Operationf ) j 




Une classe 






Une classe 






Attribut 






Attribut 






Operation( ) 






Operation( ) 











Visibility 

Les trois notations proposent les niveaux public, protege et prive, avec la meme 
semantique que celle du langage C++. Booch possede en plus un niveau 
implementation. 



Booch 


OMT 


UML 








rien non specifie 


rien public 


+ public 


+ public 


/ protege 


# protege 


# protege 


/ / prive 


- prive 


- prive 


/ / / implementation 










Metaclasse classe 


$ classe 


souligne classe 


/ Attribut public / 
/ | Attribut protege / 
{ || Attribut prive | 
s.^ Operation publiquef ) \ 
| Operation protegee) ) \ 
\ || Operation privee( ) / 




_ ^ 

+Attribut public j 
#Attribut protege I 
-Attribut prive j 

+Operation publique( )j 
#Operation protegee( j 
-Operation privee( ) | 




" ~] 

+Attribut public I 
#Attribut protege | 
-Attribut prive j 
"1 

+Operation publique( )| 
#Operation protegee( I 
-Operation privee( ) | 
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Classe abstraite 

En Booch, les classes abstraites sont designees par un petit triangle qui contient 
la lettre A. En OMT, une classe abstraite possede une multiplicite de valeur nulle. 
En UML, le nom des classes abstraites figure en italique. 



Booch 


OMT 


UML 








/ Classe ) 




Classe abstraite 






Classe abstraite 




C abstraite ( 




0 























Classe utilitaire 

En Booch et en UML, une classe utilitaire se represente comme une classe simple, 
avec en plus une bordure grisee. OMT ne propose pas d'attribut graphique 
particulier, en dehors des contraintes. 



Booch 


OMT 


UML 


/ Classe / 
V. utilitaire ( 








Classe utilitaire 
{utilitaire} 




Classe utilitaire 

«Utilitaire» 
Classe utilitaire 





Classe parametrable 

Booch et UML proposent une notation speciale, derivee de la representation des 
classes simples, avec en plus un petit rectangle pointille qui contient les 
parametres formels. OMT suffixe le nom des classes parametrables par les 
parametres formels. 
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Booch 




OMT 



Classe parametrable 
<Param> ■ 



UML 



Param 



Classe parametrable 



Classe parametree 

L'instanciation d'une classe parametrable donne une classe parametree. Booch 
propose une icone speciale, avec un rectangle en trait continu ; le parametre 
effectif peut etre represente au moyen d'une relation d'utilisation. OMT et UML 
represented les classes parametrees au moyen d'une classe simple en suffixant le 
nom de la classe par les valeurs des parametres effectifs. 



Booch 


OMT 


UML 










Classe parametree 
<Parametre effectif> 


Classe parametree 
1 <Parametre effectif>| 


y Classe / 
v... parametree f 







Metaclasse 

Booch represente une metaclasse au moyen d'une classe grisee. OMT ne 
possede pas d'attribut graphique particulier, en dehors des contraintes. UML 
stereotype une classe simple pour obtenir une metaclasse. 



Booch 


OMT 


UML 


















Metaclasse 

{Metaclasse} 




«Metaclasse» 
Metaclasse 
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Les relations 



Association 

Dans les trois notations, les associations se represented par une ligne continue, 
tracee entre les classes qui participent a 1' association. 



Booch 



OMT 



UML 





A 




B 





A 




B 





Role 



Dans les trois notations, les noms de roles sont places pres des extremites des 
relations. 



Booch 




OMT 



A 


Role 


B 





UML 



A 


Role 


B 





Multiplicity 

Booch et UML sont identiques, a part pour la valeur illimitee qui se represente par 
Wen Booch et * en UML. OMT propose une representation graphique a base de 
cercles. II faut faire attention a ne pas confondre ces cercles avec ceux des 
relation has et use de Booch, car il n'y aucun rapport entre les deux 
representations. 



Booch 



OMT 



UML 



1 

0. . 1 
N 

3.. 5, 7, 15 
3. . N 



1 par defaut 





0..N 

O • 




0..1 





3..5 

• • 






1 + 





1 

0. . 1 
* 

3.. 5, 7, 15 
3. . * 
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Restriction 

La restriction d'une association se represente en Booch au moyen d'une 
condition entre crochets. En OMT et en UML, une restriction se represente au 
moyen d'un compartiment rectangulaire. 

La cle se represente du cote source en OMT et UML, et du cote destination en 
Booch. 




Classe-association 

Dans les trois notations, une classe-association se represente au moyen d'une 
classe reliee a une association. 



Booch 






OMT 



A 




B 


-XT- 






c 





UML 



Agregation 

II n'y a pas d'equivalence stricte entre Booch d'une part, et OMT et UML d'autre 
part. 

Du point de vue des agregations, Booch est plus proche de la conception, OMT 
est plus proche de 1' analyse, et UML couvre a la fois 1' analyse et la conception. 

Le tableau suivant represente les deux situations les plus courantes : 1' agregation 
par reference et l'agregation par valeur (la composition en UML). II faut noter que 
dans le cas d'OMT, la vue graphique ne distingue pas la forme d'agregation. 
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Booch 





OMT 



UML 



A 


O 


B 











B 


O 



A 




B 


♦ 



Dependance 

Booch represente la dependance au moyen d'une association decoree d'un petit 
cercle, place du cote client. OMT represente la dependance au moyen d'une 
fleche en pointille, a tete pleine. UML represente la dependance au moyen d'une 
fleche en pointille, a tete ouverte. En OMT et en UML, la fleche designe le 
fournisseur. 



Booch 


OMT 


UML 


k f— ^ j 


r~A~] r~B~i 

! i L ' 


I l I I 
i A | ^ B ' 



Heritage 

Dans les trois notations, l'heritage se represente au moyen d'une fleche qui 
pointe de la sous-classe vers la super-classe. 
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B C 



Instantiation de Metaclasse 

Booch emploie une fleche grisee pour representer la relation ente une classe et sa 
metaclasse. OMT ne prevoit pas de notation particuliere, en dehors des 
contraintes. UML stereotype une relation de dependance. 



Booch 


OMT 


UML 




1 MetaA 1 
1 1 

{metaclasse) L 1 

/! 

/ 

/ 

/ 

r i 

1 A 1 
1 1 
l_ 1 


1 «Metaclasse» "j 
■ Meta A i 

V 1 

/ 

«Metaefasse» 

: 1 


Instanciation de generique 

Booch propose une fleche pointillee pour representer la relation entre les classes 
parametrees et les classes parametrables. OMT emploie une relation de 
dependance. UML stereotype une relation de dependance. 


Booch 


OMT 


UML 


< ( 


,-□ 

I I 
I I 

s 

s 


<<LiSKSon>> 

erf 



Construction derivee 

Les associations et les attributs derives sont prefixes par le caractere / en OMT 
comme en UML. Cette notion n'existe pas en Booch. 
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A3 

Generation de code C++ 



Les exemples de code qui suivent ont ete generes automatiquement par l'outil 
Rational Rose 4.0, a partir de modeles UML. Ces exemples n'illustrent pas 
l'ensemble des capacites de generation de code de Rose, mais decrivent les 
grandes lignes des correspondances entre UML et le langage C++. 



Classe 



Classe vide 

Le generateur de code a ete configure pour generer un constructeur, un 
constructeur par copie, un destructeur, un operateur d' affectation et deux 
operateurs d'egalite. 

Ces operations ne sont pas representees dans les paragraphes suivants, afin de 
ne pas surcharger les exemples. 

1 #ifndef A_h 

A #define A_h 1 

' ' class A 

{ 

public: 

//## Constructors (generated) 
A(); 

A(const A&right); 
//## Destructor (generated) 
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~A(); 

//## Assignment Operation (generated) 
const A & operator=(const A &right); 

//## Equality Operations (generated) 
int operator==(const A &right) const; 
int operator!=(const A Sright) const; 

}; 

#endif 

Classe avec attributs et operations 

class A 
{ 

public: 



//## Other Operations (specified) 
void Op1(); 
void Op2(); 

const String get_A1 () const; 
void set_A1 (const String value); 
const String get_A2() const; 
void set_A2(const String value); 

private: 
String A1 ; 
String A2; 



nline const String A::get_A1 () const 
return A1 ; 



inline void A::set_A1 (const String value) 
A1 = value; 



inline const String A::get_A2() const 



A1 : String 
A2 : String 



Op1() 
Op2() 



A3 - Generation de code C+ + - 383 



return A2; 

} 

inline void A::set_A2(const String value) 
{ 

A2 = value; 

} 

Classe parametrable 

template orgtype Att> 
class D 
{ 

public: 
D(); 

D(const D<Att> &right); 
~D0; 

const D<Att> & operator=(const D<Att> 
&right); 

int operator==(const D<Att> Sright) const; 
int operator!=(const D<Att> &right) const; 

}; 

Classe utilitaire 

Toutes les operations d'une classe utilitaire sont prefixees par le mot-cle 
static. 



i i 



i F 

pzzzz 

'Op1() 



|Op2( ) 



class F 
{ 

public: 
static void Op1(); 
static void Op2(); 

}; 
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Association 



Association 1 vers 1 

Le generateur de code realise 1' association par des pointeurs places dans les 
parties privees des classes qui participent a 1' association. 



A 


Ra Rb 


B 


1 1 



class A 



const B * get_Rb() const; 
void set_Rb(B "const value); 

private: 
B *Rb; 



inline const B * A::get_Rb() const 
{ 

return Rb; 



inline void A::set_Rb(B "const 
value) 



Rb = value; 



} 



class B 
{ 



const A * get_Ra() const; 
void set_Ra(A *const value); 

private: 
A *Ra; 



}; 



inline const A * B::get_Ra() const 
{ 



return Ra; 



} 



inline void B::set_Ra(A *const 
value) 

{ 

Ra = value; 

} 



Association N vers 1 



A 


Ra Rb 


B 


0..* 1 



Le generateur de code realise 1' association par des pointeurs places dans les 
parties privees des classes qui participent a 1' association. La multiplicite 0. . * 
est realisee par un ensemble de taille non contrainte. 
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class B 
{ 

const UnboundedSetByReference<A> get_Ra() const; 
void set_Ra(const UnboundedSetByReference<A> value); 

private: 

UnboundedSetByReference<A> Ra; 

}; 

inline const UnboundedSetByReference<A> B::get_Ra() const 
{ 

return Ra; 

} 

inline void B::set_Ra(const UnboundedSetByReference<A> value) 
{ 

Ra = value; 

} 

Association N vers 1 avec une contrainte 

Le generateur de code realise 1' association par des pointeurs places dans les 
parties privees des classes qui participent a 1' association. Du fait de la contrainte 
{Ordered}, la multiplicite 0. . * est realisee par une liste de taille non 
contrainte. 



A 


Ra 


Rb 


B 




0..* 1 





{Ordered} 



class B 
{ 

const UnboundedListByReference<A> get_Ra() const; 
void set_Ra(const UnboundedListByReference<A> value); 

private: 

UnboundedListByReference<A> Ra; 
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}; 



A3 - Generation de code C+ + - 387 



Classe-association 



A 




B 


1 ! 1 



class A; class B; 

class C 
{ 

const B * get_the_B() const; 
void set_the_B(B "const value); 



const A * get_the_A() const; 
void set_the_A(A "const 
value); 



private: 
A *the_A; 
B *the_B; 

}; 



#include "C.h" 
class A 
{ 

const C * get_the_C() const; 
void set_the_C(C "const value); 

private: 
C *the_C; 



#include "C.h" 
class B 
{ 

const C * get_the_C() const; 
void set_the_C(C "const value); 

private: 
C *the_C; 
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Classe-association N vers N 





#include "C.h" 
class B 
{ 

const UnboundedSetByReference<C> get_the_C() const; 
void set_the_C(const UnboundedSetByReference<C> value); 

private: 

UnboundedSetByReference<C> the_C; 

}; 



Agregation 



Agregation 1 vers 1 




i 



#include "B.h" 
class A 



#include "A.h l 
class B 



const B * get_the_B() const; 
void set_the_B(B *const value); 



const A * get_Ra() const; 
void set_Ra(A *const value); 



private: 
B *the_B; 



private: 
A *Ra; 



}; 



}; 
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Agregation a navigabilite restreinte 



A 


& O 


B 




1 1 



class A 



private: 



#include "A.h" 
class B 
{ 

const A * get_Ra() const; 
void set_Ra(A *const value); 
private: 
A *Ra; 

}; 



Agregation par valeur 



A 


Ra # 


B 


1 1 



#include "B.h" 
class A 



const B * get_the_B() const; 
void set_the_B(B *const value); 

private: 
B*the B; 



#include "A.h" 
class B 
{ 

const A get_Ra() const; 
void set_Ra(const A value); 



private: 
ARa; 



}; 



Agregation par valeur 1 vers N 



Ra 



#include "A.h" 
class B 
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{ 

const UnboundedSetByValue<A> get_Ra() const; 
void set_Ra(const UnboundedSetByValue<A> value); 

private: 

UnboundedSetByValue<A> Ra; 

}; 



Heritage 



Heritage simple 



#include "A.h" 
class B : public A 
{ 



}; 



Heritage multiple 




#include "A1.h" 

#include "A2.h" 

class B : public A2, public A1 

{ 



}; 



A4 

Generation de code Java 



Les exemples de code qui suivent ont ete generes automatiquement par l'outil 
Rational Rose 4.0, a partir de modeles UML. Ces exemples n'illustrent pas 
l'ensemble des capacites de generation de code de Rose, mais decrivent les 
grandes lignes des correspondances entre UML et le langage Java. 

Classe 



Classe vide 

Le generateur de code a ete configure pour generer un constructeur et un 
destructeur. Ces operations ne sont pas representees dans les paragraphes 
suivants, afin de ne pas surcharger les exemples. 

1 public final class A { 



public A() { 
super(); 

} 

protected void finalize() throws Throwable { 
super.finalize(); 

} 



} 
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Classe avec attributs et operations 

public final class A { 

private String m_A1 ; 
private String m_A2; 

public void Op1() { 
} 

public void Op2() { 
} 

Classe abstraite 

~ public abstract class A { 

' ' I 




Interface 



«lnterface» 
I A 



public interface l_A { 



Association 



Association 1 vers 1 



public class A { 
public B m_Rb; 

} 



A 


Ra Rb 


B 


1 1 



public class B { 
public A m_Ra; 

} 



Association N vers 1 
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Ra 



Rb 



B 




A 







-Ra 



Rb 



public class B { 

public Vector m_Ra = new 
VectorQ; 



} 



public class B { 

private Vector m_Ra = new 
VectorQ; 



} 



Lorsque la multiplicite est limitee l'association est realisee par un tableau. 

public class B { 

private A[] m_Ra = new A[5]; 

} 



A 


-Ra Rb 


B 


5 1 



Agregation 



Agregation 1 vers 1 



A 


Ra 




< 

1 



public class A { 
public B m_B; 

} 



public class B { 
public A m_Ra; 

} 
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Agregation a navigabilite restreinte 



ipa. 



-O 
1 L 



public class A { 



public class B { 
public A m_Ra; 

} 



Heritage 



Heritage simple 



public class B extends A { 



Heritage entre interfaces 



«lnterface» 
I A 



«lnterface» 
I C 



«lnterface» 
I B 



«lnterface>; 
I A 



>«lnterface»i 
I C 



public interface l_C extends l_A { 



public interface l_C extends l_A, l_B 
{ 



} 
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Realisation d'une interface par une classe abstraite 



l«lnterface» 
I A 



public abstract class A implements 
LA{ 



} 



Realisation d'une interface par une classe 



«lnterface» 
I A 



public class A implements l_A { 



Realisation de plusieurs interfaces par une classe 



K<lnterface>^ «mterrace>; 



I B 



;lnterface> 



public class A implements l_A, l_B { 



A5 

Generation de code IDL 



Les exemples de code qui suivent ont ete generes automatiquement par l'outil 
Rational Rose 4.0, a partir de modeles UML. Ces exemples n'illustrent pas 
l'ensemble des capacites de generation de code de Rose, mais decrivent les 
grandes lignes des correspondances entre UML et le langage IDL. 



Classe 

Classe vide 

Une classe est traduite en interface IDL. 

1 interface A { 



1 1 }; 

Classe avec attributs et operations 

interface A { 
attribute String Att1 ; 
attribute String Att2; 



void Op1(); 
void Op2(); 

}; 



A1 : String 
A2 : String 



Op1() 
Op2() 
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Association 



Association 1 vers 1 



A 


Ra Rb 


B 
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interface A { 
attribute B Rb; 

}; 

Association N vers 1 



A 


Ra 


Rb 


B 




1 



Association 5 vers 1 



A 


-Ra Rb 


B 
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interface B { 
attribute A Ra; 

}; 



interface B { 

attribute sequence<A> Ra; 

}; 



interface B { 

attribute sequence<A,5> Ra; 

}; 



Agregation 



Agregation 1 vers 1 



A 


Ra 




< 

1 
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interface A { 
attribute B the_B; 

}; 



interface B { 
attribute A Ra; 

}; 



Agregation a navigabilite restreinte 



interface A { 



-o 

1 



interface B { 
attribute A Ra; 

}; 



Heritage 



Heritage simple 



Heritage multiple 



A1 



A2 



interface B : A { 



interface B : A1 , A2 { 



A6 



Generation de code 
Visual Basic 



Les exemples de code qui suivent ont ete generes automatiquement par l'outil 
Rational Rose 4.0, a partir de modeles UML. Ces exemples n'illustrent pas 
l'ensemble des capacites de generation de code de Rose, mais decrivent les 
grandes lignes des correspondances entre UML et le langage Visual Basic. 



Classe 



Classe vide 

1 Option Base 0 



Private Sub Class_lnitialize() 
End Sub 

Private Sub Class_Terminate() 
End Sub 
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Classe avec attributs et operations 



A 



Option Base 0 



A1 : String 
A2 : String 



Public A1 As String 




Public A2 As String 



Private Sub Class_lnitialize() 
End Sub 

Private Sub Class_Terminate() 
End Sub 

Public Sub0p1() 
On Error GoTo Op1 Err 



Exit Sub 
Op1 Err: 

Call RaiseError(MyUnhandledError, "A:0p1 
Method") 
End Sub 

Public Property Get Op2() As Boolean 
On Error GoTo Op2Err 



Exit Property 
Op2Err: 

Call RaiseError(MyUnhandledError, "A:0p2 
Property") 
End Property 



Classe utilitaire 



F 



Option Base 0 



Op1() 
Op2() 



Private Sub Class_lnitialize() 
End Sub 

Private Sub Class_Terminate() 
End Sub 
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Public Sub0p1() 
End Sub 

Public Property Get 0p2() As Boolean 
End Property 



Association 



Association 1 vers 1 



A 
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Option Base 0 
Public Rb As B 

Private Sub Class_Terminate() 
End Sub 

Private Sub Class_lnitialize() 
End Sub 



Option Base 0 
Public Ra As A 

Private Sub Class_Terminate() 
End Sub 

Private Sub Class_lnitialize() 
End Sub 



Association N vers 1 



A 


Ra Rb 


B 


1 



Option Base 0 

Public Rb As B 

Private Sub Class_lnitialize() 
End Sub 

Private Sub Class_Terminate() 
End Sub 



Option Base 0 

Public Ra As Collection 

Private Sub Class_lnitialize() 
End Sub 

Private Sub Class_Terminate() 
End Sub 
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Heritage 



Heritage simple 



A 




B 


0p1() 


< 


0p2() 



Option Base 0 
Implements A 

'local superclass object (generated) 
Private mAObject As New A 

Private Sub Class_lnitialize() 
End Sub 

Private Sub Class_Terminate() 
End Sub 

Public Sub 0p2() 
End Sub 

Private Sub A_0p1 () 

mAObject. Op1 
End Sub 



A7 

Generation de code SQL 



Les exemples de code qui suivent ont ete generes automatiquement par l'outil 
Rational Rose 4.0, a partir de modeles UML. Ces exemples n'illustrent pas 
l'ensemble des capacites de generation de code de Rose, mais decrivent les 
grandes lignes des correspondances entre UML et le langage SQL ANSI. 

Pour une discussion detaillee sur la generation de code SQL a partir d'un 
diagramme de classes et les differentes strategies possibles, voir le chapitre 17 du 
livre Object-Oriented Modeling and Design 48 . 



Classe 



Classe vide 



A 



CREATE TABLE T_A ( 
AJd NUMBER (5), 
PRIMARY KEY (AJd) 

) 



4S Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W. 1991, Object- 
Oriented Modeling and Design. Prentice Hall. 
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Classe avec attributs et operations 

Le generateur construit la structure statique, les operations sont ignorees. 



A 

A1 : String 
A2 : String 



CREATE TABLE T_A ( 
AJd NUMBER (5), 
Att1 VARCHAR (), 
Att2 VARCHAR (), 
PRIMARY KEY (AJd) 

) 



Association 



Association 1 vers 1 



A 
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Rb 


B 
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CREATE TABLE T_B ( 
BJd NUMBER (5), 
PRIMARY KEY (BJd) 

) 



CREATE TABLE T_A ( 
AJd NUMBER (5), 

BJd NUMBER (5) REFERENCES TJ3 (BJd), 
PRIMARY KEY (AJd) 

) 



Association N vers 1 



A 


Ra Rb 


B 
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CREATE TABLE TJ3 ( 
BJd NUMBER (5), 
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PRIMARY KEY (BJd) 

) 



CREATE TABLE T_A ( 
BJd NUMBER (5) REFERENCES T_B (BJd), 
AJd NUMBER (5), 
PRIMARY KEY(AJd) 

) 



Classe-association N vers N 



i 



1 A "I , | B "I 

Jo..* | o..*! 1 

i 
i 

i — ' — i 

i u i 
i i 



CREATE TABLE T_A ( 
AJd NUMBER (5), 
PRIMARY KEY (AJd) 



CREATE TABLE T_B( 
BJd NUMBER (5), 
PRIMARY KEY (BJd) 

) 



CREATE TABLE T_C ( 

AJd NUMBER (5) REFERENCES T_A (AJd) ON DELETE CASCADE, 
BJd NUMBER (5) REFERENCES TJ3 (BJd) ON DELETE CASCADE, 
PRIMARY KEY(AJd, BJd) 

) 



Heritage 

Dans les exemples suivants chaque classe est realisee par une table. L'identite 
d'un objet est preservee dans la hierarchie de classes par l'emploi d'un identifiant 
partage. 
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Heritage simple 



A 

A 



B 



CREATE TABLE T_A( 
AJd NUMBER(5), 
PRIMARY KEY(AJd) 

) 

CREATE TABLE T_B( 

AJd NUMBER (5) REFERENCES T_A (AJd), 
PRIMARY KEY(AJd)) 

) 



Heritage multiple 



CREATE TABLE T_A1( 
A1 Jd NUMBER(5), 
PRIMARY KEY(A1 Jd)) 

CREATE TABLE T_A2( 
A2Jd NUMBER(5), 
PRIMARY KEY(A2Jd) 



A1 



A2 



CREATE TABLE T_B( 

A1 Jd NUMBER (5) REFERENCES T_A1 (A1 Jd), 
A2Jd NUMBER (5) REFERENCES T_A2 (A2Jd), 
PRIMARY KEY(A1 Jd ,A2Jd) 

) 



Glossaire 



Abstraction 

Abstraite 
Acteur 

Action 

Activite 

Agent 
Agregation 

Algorithme 
Analyse 

Analyse des besoins 
Analyse du domaine 

Ancetre 
Application 
Architecte 
Architecture 



Faculte des humains de se concentrer sur l'essentiel et d'oublier 
les details. Parfois employe comme synonyme de classe. 

Se dit d'une classe qui ne peut pas etre instanciee directement. 

1) Classe de personnes ou de systemes qui interagissent avec un 
systeme. 

2) Objet toujours a l'origine d'une interaction. 

Operation executee instantanement lors d'une transition d'un 
etat vers un autre etat. Une action ne peut pas etre interrompue. 

Operation executee au sein d'un etat. Une activite est 
interruptible. 

Objet qui peut etre origine et destination d'une interaction. 

Forme d' association non symetrique qui exprime un couplage 
fort et une relation de subordination. 

Enchainement des actions necessaires a une tache. 

Determination du quoi et du quoifaire d'une application. 

Determination des besoins des utilisateurs. 

Partie de 1' analyse qui se concentre sur l'environnement de 
1' application. 

Synonyme de super-classe. 

Systeme logiciel elabore dans un but precis. 

Specialiste de 1' architecture. 

1) Art de construire ; en informatique, art de construire les 
logiciels. 
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2) Structure d'un logiciel. 



Artefact 

Association 
Association derivee 
Asynchrone 

Attribut 
Attribut de lien 

Attribut derive 
Automate 
Big bang 

Cardinality 
Cas d'utilisation 

Categorie 

Classe 

Classe abstraite 

Classe active 
Classe concrete 

Classe de base 
Classe parametrable 
Classe parametree 

Classe racine 

Classe utilitaire 

Classe-association 

Classification 

Classification 
dynamique 



Element d' information, produit ou consomme par une des 
activites lors du developpement d'un logiciel. 

Relation entre classes qui decrit un ensemble de liens. 

Association deduite d'autres associations. 

Forme de communication non bloquante et sans accuse de 
reception. 

Information contenue par un objet. 

Attribut appartenant a un lien entre objets, plutot qu'aux objets 
eux-memes. 

Attribut deduit d'autres attributs. 

Forme de representation abstraite du comportement. 

Se dit de la technique d' integration lorsqu'elle est concentree en 
fin de developpement. 

Nombre d' elements dans une collection. 

Technique d'elaboration des besoins fonctionnels, selon le point 
de vue d'une categorie d'utilisateurs. 

Sorte de paquetage de la vue logique ; une categorie encapsule 
des classes. 

Description abstraite d'un ensemble d'objets ; realisation d'un 
type. 

Classe qui ne s'instancie pas directement et qui sert uniquement 
de specification. 

Classe dont les objets sont actifs. 

Par opposition aux classes abstraites, classe qui s'instancie 
pour donner des objets. 

Classe racine d'une hierarchie de classes. 

Classe modele pour la construction de classes. 

Classe resultant de la parametrisation d'une classe 
parametrable. 

Classe racine d'une hierarchie de classes. 

Classe degradee, reduite au concept de module. 

Association promue au rang de classe. 

Action d'ordonner dans le but de comprendre. 

Forme de classification par laquelle un objet peut changer de 
type ou de role. 



Classification 



Forme de classification par laquelle un objet ne peut pas 
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statique changer de type ou de role. 

Cle Tuple des attributs qui realisent la restriction d'une association. 

Cle naturelle Cle primaire issue du domaine de 1' application. 

Cle primaire Information designant un objet de maniere bijective. 

Client Objet a l'origine d'une requete. 

Collaboration 1) Se dit d'une interaction entre objets realisee dans le but de 

satisfaire un besoin de l'utilisateur. 

2) Element structurant d'UML pour la description du contexte 
d'une interaction. 

Collection Terme generique designant tous les regroupements d'objets sans 

preciser la nature du regroupement. 

Composant Element physique constitutif d'une application, represents; 

principalement dans la vue de realisation. 

Composition 1) Forme d' organisation complementaire de la classification. 

2) Agregation par valeur. 

Conception Determination du comment d'une application. 

Condition Expression booleenne qui valide ou non une transition dans un 

automate d'etats finis. 

Constructeur Operation de classe qui construit des objets. 

Construction Phase de la vue de l'encadrement dans laquelle le logiciel est 

realise et amene a un etat de maturite suffisant pour etre livre a 
ses utilisateurs. 

Conteneur Structure de donnees qui contient des objets. 

Contexte Ensemble d'elements de modelisation qui sert de support a une 

interaction. 

Contrainte Expression qui precise le role ou la portee d'un ou plusieurs 

elements de modelisation. 

Contrat Engagement entre classes redige selon les termes de la 

specification du fournisseur. 

Controle Synonyme de flot de controle. 

Couche Segmentation horizontale des modeles. 

Couplage Dependance entre elements de modelisation. 

CRC Abreviation de Class Responsibilities Collaborators. 

Cycle Passage complet par les quatre phases de la vue de 

l'encadrement. 

Cycle de vie Etapes du developpement et ordonnancement de ces etapes. 

Decomposition Separation en elements plus petits dans le but de reduire la 

complexite. 
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Delegation 

Dependance 
Deploiement 

Destructeur 

Diagramme 

Discret 

Discriminant 

Documentation 

Domaine 

Elaboration 

Element 

Element de 
modelisation 

Element de 
visualisation 

Encapsulation 

Entite 

Enumeration 
Erreur 

Espace de nom 

Espace des etats 
Etat 

Etend 

Etude d'opportunite 

Evenement 
Exception 



Mecanisme de communication entre objets qui permet a un 
objet fournisseur de faire realiser des taches par un objet sous- 
traitant, sans le dire a l'objet client. 

Relation d' obsolescence entre deux elements de modelisation. 

Phase de la vue de l'encadrement qui comprend la transition de 
1' application dans son environnement final. 

Operation de classe qui detruit des objets. 

Representation graphique d'elements de modelisation. 

Contraire de continu. 

Synonyme de critere. 

Description textuelle des modeles. 

Synonyme de champ d' application. 

Phase de la vue de l'encadrement dans laquelle l'architecture est 
definie. 

Brique de base d'un modele. 

Representation d'une abstraction issue du domaine du 
probleme. 

Projection graphique d'une collection d'elements de 
modelisation. 

Occultation des informations contenues par un objet. 

Terme emprunte aux methodes de modelisation par les 
donnees ; il est employe comme synonyme d' objet du domaine. 

Liste de valeurs nominees ; domaine de definition d'un type. 

Occurrence anormale. 

Partie de modele dans laquelle un nom peut etre defini : au sein 
d'un espace de nom, un nom ne possede qu'une seule 
signification. 

Ensemble des etats possibles. 

Condition instantanee dans laquelle se trouve un objet, un 
systeme. 

Relation d'extension entre cas d'utilisation. 

Phase de la vue de l'encadrement dans laquelle la vision du 
produit est definie. 

Occurrence qui engendre un changement d'etat. 

Condition exceptionnelle qui correspond a une anomalie lors de 
1' execution. 



Export 



Partie visible d'un paquetage. 
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Expression 
Extension 

Factorisation 
Flot d'execution 
Flot de controle 
Flot de donnees 

Fonction 

Framework 
Garde 

Generalisation 



Generalisation 
multiple 

Generation 

Generique 

Gestion de versions 

Gestion de 
configurations 

Heritage 

Heritage d'interface 

Heritage de (pour la) 
realisation 

Heritage multiple 

Hierarchie 

Identite 

Idiome 
Import 



Chaine dont 1' interpretation donne une valeur d'un type donne. 

Forme de programmation qui facilite la prise en compte de 
nouveaux besoins. 

Identification puis extraction de similitudes entre classes. 
Description de la repartition de l'activite entre les objets. 
Synonyme de flot d'execution. 

Description des donnees qui transitent d'un objet vers un autre 
objet. 

Expression d'un besoin en termes imperatifs, sous la forme de 
laches a accomplir. 

Macro-architecture generique. 

Condition booleenne qui valide une transition dans un automate. 

Point de vue ascendant porte sur une classification ; nom donne 
par UML a la relation de classification utilisee pour construire 
des hierarchies de classes ; souvent synonyme d heritage, bien 
que plus abstrait. 

Forme de generalisation dans laquelle une classe derive de 
plusieurs ancetres. Souvent synonyme d'heritage multiple, bien 
que plus abstrait. 

Derniere version executable produite par un cycle de 
developpement. 

Solution generate ; se dit aussi de composants modeles. 

Enregistrement de l'histoire d'un element. 

Etablissement de relations entre les constituants d'un systeme 
dans le but de maintenir la coherence. 

Relation entre classes qui permet le partage de proprietes 
definies dans une classe ; principale technique de realisation de 
la generalisation. 

Heritage de l'interface d'un element plus general sans sa 
realisation. 

Heritage de l'interface et de la realisation d'un element plus 
general. 

Relation entre classes qui permet le partage de proprietes 
definies dans plusieurs classes. 

Arborescence de classes ordonnees par une relation de 
generalisation. 

Caracteristique fondamentale d'un objet qui le distingue de tous 
les autres objets. 

Construction elegante, propre a un langage donne. 

Relation de dependance entre paquetages qui rend visible les 
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Instance 

Integration 

Interaction 

Interface 

Interruption 

Invariant 

Invocation 
Iterateur 

Iteration 

Liaison dynamique 
Liaison statique 
Lien 

Ligne de vie 

Livraison 

Maintenance 

Mecanisme 
Membre 

Message 
Metaclasse 



exports d'un paquetage au sein d'un autre paquetage. 

Synonyme d'objet ; un objet est instance d'une classe. 

Qualite de l'interdependance entre elements de modelisation. 

Description d'un comportement dans le contexte d'une 
collaboration. 

Partie visible d'une classe, d'un groupe d'objets ; parfois 
synonyme de specification. 

Deroutement du flot d' execution normal, consecutif a la 
detection d'une condition materielle. 

1) Expression booleenne dont le changement de valeur declenche 
une exception. 

2) Critere pour la detection des objets ; un objet est un invariant 
du domaine. 

Mecanisme par lequel un message declenche une operation. 

Objet ou mecanisme qui permet de visiter tous les elements 
d'une collection, sans en devoiler la structure interne. 

1) Action de traverser une collection d'objets. 

2) Sequence d'activites de la vue technique qui aboutit a la 
livraison d'un prototype executable. 

Association entre un nom d'objet et une classe realisee a 
1' execution. 

Association entre un nom d'objet et une classe realisee a la 
compilation. 

Connexion semantique entre un tuple d'objets par laquelle un 
objet peut communiquer avec un autre objet. 

Representation de l'existence d'un objet dans un diagramme de 
sequence. 

Resultat executable d'une iteration ; parfois synonyme de 
prototype. 

Phase du cycle de vie du logiciel qui suit le deploiement ; la 
maintenance regroupe des activites de correction de defauts et 
de prise en compte des demandes d'evolution. 

Synonyme de collaboration entre objets. 

Terminologie C++ pour designer un attribut ou une operation 
contenue par une classe. 

Element de communication entre objets qui declenche une 
activite dans 1' objet destinataire ; la reception d'un message 
correspond a un evenement. 

Classe d'une classe ; elle contient les donnees et les operations 
qui concernent la classe plutot que les instances de la classe. 
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Metamodele 
Metamodelisation 

Methode 



Methode d'instance 
Methode de classe 
Mode 

Modele 
Modelisation 

Modificateur 
Modularity 

Module 

Monomorphisme 

Multiplicity 

Navigabilite 

Niveau de maturity 
Noeud 

Non interprete 
Notation 

Note 

Objet 
Objet actif 
Occultation 



Modele qui decrit des elements de modelisation. 

Modelisation recursive des elements de modelisation a partir 
d'eux-memes. 

1) Souvent synonyme d' operation ; quelquefois utilise pour 
distinguer la specification de 1' operation des multiples 
realisations - les methodes - implantees dans les sous-classes. 

2) Ensemble de demarches raisonnees pour parvenir a un but. 
Operation qui concerne les objets. 

Operation qui concerne la classe plus que les objets. 

Caracterise les parametres selon la direction du flot de donnees : 
en entree, en entree et en sortie, en sortie. 

Construction descriptive a partir des elements de modelisation. 

Synonyme d' analyse ; par extension, elaboration des modeles, y 
compris de conception. 

Operation qui modifie l'etat interne d'un objet. 

Qualite d'un environnement de realisation qui permet la 
partition. 

Espace lexical dans lequel d'autres constructions peuvent etre 
declarees. 

Concept de la theorie des types, selon lequel un nom ne peut 
referencer que des objets de la meme classe. 

Designe le nombre d' objets qui peuvent participer a une 
relation. 

Qualite d'une relation qui permet le passage d'une classe vers 
une autre classe. 

Description de la qualite d'un processus de developpement. 

Dispositif materiel susceptible d'executer un programme. 

Representation d'un type non specifie par UML, sous la forme 
d'une chaine. 

Ensemble des signes et symboles qui composent un langage. 
Dans le cas d'UML, ensemble des representations graphiques 
et textuelles qui constituent les diagrammes. 

Information textuelle qui peut etre associee a tout element ou 
combinaison d' elements de modelisation ; la note appartient a la 
vue, elle ne vehicule aucune semantique. 

Entite atomique constituee d'un etat, d'un comportement et 
d'une identite. 

Objet qui possede son propre flot de controle ; instance d'une 
classe active. 

Synonyme d' encapsulation. 
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d'information 
Operation 

Operation abstraite 

Paquetage 
Partie privee 

Partie protegee 

Partie publique 

Partition 

Pattern 

Persistance 
Phase 

Polymorphisme 

Post-condition 
Pre-condition 

Processus 



Projection 
Propriete 
Prototype 
Pseudo-etat 

Recursivite 

Reflexive 

Reification 

Responsabilite 



Element de comportement des objets, defini de maniere globale 
dans la classe. 

Operation definie dans une classe, mais dont la realisation est 
reportee dans une sous-classe. 

Element d' organisation des modeles. 

Partie de la specification d'une classe qui regroupe des 
proprietes invisibles de l'exterieur. 

Partie de la specification d'une classe qui regroupe des 
proprietes invisibles de l'exterieur, sauf des sous-classes. 

Partie de la specification d'une classe qui regroupe des 
proprietes visibles de l'exterieur. 

Segmentation verticale des modeles ; par extension, sous- 
ensemble d'un modele. 

Micro-architecture ; element de conception (ou d' analyse) 
recurrent. 

Qualite d'un objet a transcender le temps ou l'espace. 

Ensemble des activites entre deux points de controle d'un 
processus de developpement. 

Concept de la theorie des types, selon lequel un nom peut 
referencer des objets instances de plusieurs classes regroupees 
dans une hierarchie de generalisation. 

Condition booleenne qui doit etre vraie apres l'execution d'une 
operation. 

Condition booleenne qui doit etre vraie avant l'execution d'une 
operation. 

1) Flot d' execution lourd. 

2) Suite d'etapes, plus ou moins ordonnees, dediees a la 
satisfaction d'un objectif. 

Relation entre un ensemble et un sous-ensemble. 
Caracteristique d'une classe. 

Resultat d'une iteration ; version partielle d'un systeme. 

Designe des etats particuliers comme l'etat initial, l'etat final, 
l'historique. 

Application d'une regie a ses propres resultats pour generer une 
sequence infinie de resultats. 

Se dit d'une relation dont les roles concernent la meme classe. 
Action de chosifier un concept, une fonction. 
Obligation d'une classe ; partie de sa raison d'etre. 
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Restriction 

Retro-ingenierie 

Reutilisation 

Revue 

Risque 

Role 

Scenario 

Scheme 

SKI 

Selecteur 



Serveur 

Signal 

Signature 

Sous-classe 

Sous-etat 
Sous-systeme 

Specialisation 

Specification 

Stereotype 

Structure 

Structured 

Super-classe 
Super-etat 



Se dit d'une relation dont la portee a ete reduite par une 
contrainte ou une cle. 

Reconstruction des artefacts des activites en amont, a partir des 
artefacts des activites en aval. 

Usage poursuivi ou repete d'un artefact du developpement. 

Revision formelle d'une documentation, d'un modele. 

Element susceptible de perturber le bon deroulement du 
developpement. 

Extremite d'une relation ; par extension, maniere dont les 
instances d'une classe voient les instances d'une autre classe au 
travers d'une relation. 

Interaction simple entre objets. 

Traduction francaise de pattern. 

Software Engineering Institute. 

1) Operation qui renseigne sur l'etat interne d'un objet, sans le 
modifier. 

2) Dans une expression de navigation, association qui 
partitionne un ensemble d'objet a partir de la valeur d'une cle. 

Objet qui n'est jamais a l'origine d'une interaction. 

Evenement nomme qui peut etre declenche explicitement. 

Identifiant non ambigu d'une operation, construit a partir du 
nom de 1' operation et de ses parametres. 

Classe specialisee, reliee a une autre classe plus generale par une 
relation de generalisation. 

Etat englobe par un super-etat. 

Sorte de paquetage de la vue de realisation ; un sous-systeme 
contient des elements de realisation ; il est le pendant de la 
categorie definie dans la vue logique. 

Point de vue descendant porte sur une classification. 

Description exhaustive d'un element de modelisation. 

Extension de la semantique d'un element du metamodele. 

Relations statiques entre elements de modelisation. 

Decrit une technique de decomposition, basee sur la notion de 
modules et la description des flots de donnees entre ces 
modules. 

Classe generale reliee a une autre classe plus specialisee par une 
relation de generalisation. 

Etat contenant des sous-etats. 
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Surcharge 

Synchrone 

Synchronisation 
Temps reel 

Test 

Topologie 
Transition 



Transition 
automatique 

Typage 
Type 

Type de donnee 
abstrait 

Type primitif 

Use case 

Variable d'instance 
Variable de classe 
Visibilite 

Vision 
Vue 



Emploi d'un meme nom pour designer differentes 
constructions ; la surcharge est resolue statiquement par les 
compilateurs en fonction du contexte et de la signature des 
operations. 

Forme de communication bloquante, avec accuse de reception 
implicite. 

Expression de la forme de communication entre deux objets. 

Caracteristique d'un logiciel dont le temps de reponse est 
compatible avec la dynamique du systeme. 

Ensemble des mesures et des activites qui visent a garantir le 
fonctionnement satisfaisant du logiciel. 

Decrit la repartition des modules, ainsi que des donnees et des 
operations dans ces modules, au sein d'une application. 

1) Connexion entre deux etats d'un automate, declenchee par 
l'occurrence d'un evenement. 

2) Phase de la vue de l'encadrement dans laquelle le logiciel est 
transfere a ses utilisateurs. 

Transition declenchee des que l'activite en cours dans l'etat 
s'acheve. 

Maniere dont les langages de programmation supportent la 
notion de type. 

Description d'un ensemble d' instances qui partagent des 
operations, des attributs abstraits, des relations et des 
contraintes. 

Description d'une donnee en termes operatoires. 



Type de base predefini par UML. 
Voir cas d' utilisation. 
Attribut d'objet. 

Attribut qui concerne la classe plus que les objets. 

Niveau d' encapsulation des attributs et des operations dans les 
classes. 

Definition d'un produit et de sa portee. 

Maniere de regarder des elements de modelisation, 
eventuellement issus de modeles differents. 
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Adresses utiles sur Internet 

Specifications d'UML 1.0 (Rational Software) 

Document en anglais aux formats HTML ou PDF compose de six sections : 

• UML Summary : introduction a UML. 

• UML Notation Guide : description de la notation unifiee avec exemples d' illustration. 
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• UML Semantics : description du metamodele qui est a la base de la semantique 
d'UML. 

• UML Glossary : glossaire de la terminologie UML. 

• UML Process-Specific Extensions : extensions specifiques pour la representation 
des processus de developpement. 

http : //www. rational . com/uml/ 

Rational Rose 

Outil de modelisation supportant les notations Booch'93, OMT-2 et UML. 
http : //www. rational . com/pst/products/rosefamily. html 

Site web de I'ESSAIM 

(Ecole superieure des sciences appliquees pour I'ingenieur- Mulhouse) 
Informations generales sur UML (site de l'auteur). 
http : //www. essaim . univ-mulhouse . fr 
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abstraction • 219 

demarche d' • 36, 206 

hierarchie d' • 49 

niveau d' • 61, 71, 218, 235 

acteur 

candidats • 127 

cas d'utilisation • 124 

comportement • 26 

action • 168 

declenchement • 146, 181 

activite • 168 

diagramme d' • 182 
periode d' • 155 

agent • 26 

agregation • 46, 109 
automate a • 161 
composite • 141 
composition • 110 

Agregation 
d'etats • 173 

analyse 

des besoins • 216, 276 
des risques • 261 
methode d' • 5 
objet • 205 



approche 

cognitive • 206 
fonctionnelle • 7, 25 
objet • 15 

structured • 136, 204 
systemique • 206 

approches • 206 

architecture • 208, 237 
conception • 217 
macro— • 234 
micro— • 231 
vision de 1' • 219 

Architecture «217, 219 

association • 44, 99 
a couplage fort • 46 
reflexive • 107, 139 
ternaire • 101, 140 

asynchrone 

communication • 166 
envoi de message • 31, 

attribut • 20, 37, 94 
derive • 96 

automate • 161 
amemoire • 175 
agregation • 173 
evenement • 165 
garde • 167 
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generalisation • 171 
souche «173 
transition • 164 

B 

big bang 
effet • 244 

Booch 
Grady • 9 
methode de • 9, 12 

C 

cas d'utilisation • 124, 152, 162, 182, 
192, 216, 224 
diagramme de • 126 
transition vers l'objet • 224 

changement de paradigme • 7 

classe • 36 

abstraite • 57, 118 
active • 120 
contrat de • 40 
diagramme de • 94 
parametrable • 98 
specification de • 40, 53 
utilitaire • 99 

classification • 49 
difficulty de • 59 
dynamique • 63, 115 
multiple • 63 
proprietes des • 69 

cle 

naturelle • 23 

restriction d'association • 108 
valeur de • 142 

collaboration • 136 
contexte d'une • 136 
diagramme de • 33, 142 



metamodele • 149 

realisation des cas d'utilisation • 

136, 216, 276 
realisation des patterns • 232 
representation du comportement • 

224 

collection • 40, 7 1 
multiplicity • 104 
parametrable • 98 

complexite 

crise du logiciel • 200 

cycle iteratif • 250 

des besoins • 125 

des logiciels • 201 

gestion de la • 17, 36, 49, 140, 193, 

214 
risque • 267 
transfert de la • 210 

composant 
agregation • 46 
diagramme de • 187 
heritage • 64 

integration des • 244, 266 
metamodele • 120 
reutilisable • 98, 207, 277 
stockage du code • 226 
topologie des • 237 

composants 

diagramme de • 187 

composition 
agregation • 110 
automate • 173 
generalisation et • 1 14 
heritage et • 64 

conception • 207 
architecture • 217 
cycle de vie • 245, 257, 282 



426 - Modelisation objet avec UML 



objet • 207 
pattern • 23 1 
retouche de • 251 

condition 
activite • 183 
automate • 164 
boucle • 159 
branchement • 147 
garde • 167, 174 

congere 
effet • 280 

constructeur 
d'interfaces • 135 
d'outils • 87 
message* 28, 104, 381 

conteneur • 89 

contexte 

de collaboration • 136, 149, 224, 232 
de diagramme • 44, 84, 94 
diagramme d'objet • 137 
interaction • 33, 142 

contrainte • 88 

association • 100, 106 

d'architecture • 219 

de developpement • 200 

de generalisation • 50, 116 

de realisation • 23, 209 

d'objet • 144 

heritage • 64, 115 

mecanisme commun • 86 

multiplicite • 104 

principe de substitution • 69, 75 

temporelle • 152, 158 

contrat 

de classe • 40 

de maintenance • 201 



programmation par • 21 1 

controle 

activite • 182 
automate • 179 
de la qualite • 256 
Hot de • 26, 35 
mode de • 157 
objet actif • 145 
tache • 189 

couche 

architecture • 235 
prototype • 264 

couplage 

agregation • 46 
association • 103 
cycle de vie • 240 
delegation • 67 
encapsulation • 41 
generalisation • 62 
heritage • 115 
polymorphisme • 71 

covariance • 60 
et delegation • 68 

cycle de vie 

cas d'utilisation • 124 
couverture du • 9 
des objets • 19 

diagramme de sequence • 152 
en cascade • 241 

Cycle de vie 

iteratif et incremental • 239 

D 

decomposition 
automate • 171 
cas d'utilisation • 136 
couplage • 103 
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covariante • 59 
en sous-systemes • 192 
flot d'execution • 220 
fonctionnelle • 16 
generalisation • 116 
objet • 16 

paquetage • 90, 227 
processus de • 16 

decouplage 

polymorphisme • 7 1 

delegation • 67 
agent • 27 

dependance 
automate • 174 
composant • 188 
de compilation • 226 
import «91,235 
obsolescence • 92 
relation de • 88, 123 

deploiement 

diagramme de • 194 
graduel • 267 
post- «267, 281 
vue de • 220 

Deploiement 

du code executable • 226 

destructeur 

message • 28, 381 

diagramme 

d'etats-transitions • 161 

d'objets • 137 

d'activites • 182 

de cas d'utilisation • 126 

de classes • 94 

de collaboration • 142 

de composants • 187 



de deploiement • 194 
de sequence • 151 

discriminant 

generalisation • 116 

documentation • 249 

cas d'utilisation • 128, 135, 152 
cycle de vie • 247 
de l'architecture • 223 
sous-systeme • 193 

domaine • 204 
classe du • 225 
complexite du • 201, 250 
de definition • 20, 40, 123 
du probleme • 17 
evenement • 165 
expert du • 125, 266 
generalisation • 5 1 
modelisation du • 205, 216, 275 
objet du • 36, 94, 136 

E 

effet 

big bang* 244, 251 
congere • 280 

elaboration 

cycle de vie • 257, 260 
phase d' • 275 

encapsulation • 41 
couplage • 43 
niveau d' • 42 
paquetage • 92 
sous-systeme • 193 

envoi de message 
asynchrone • 31, 153 
synchrone • 30, 153 

erreur 
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traitement d' • 93, 209 

espace de noms • 91 

espace des etats 

segmentation de 1' • 174, 203, 240 

etats-transitions 
diagramme d' • 161 

exception 

de classification • 59 
traitement d'erreur • 209 

extension 

d'UML«86, 361 

par specialisation • 50, 118 

relation d' • 130 

F 

factorisation 

des proprietes • 56 
simplification par • 174, 210 

flot 

d' execution • 30, 120, 146, 153, 155, 

184, 220 
de controle • 28, 152, 183, 371 
de donnees • 28, 152, 371 

formation • 257, 267, 272, 280 
plan de • 213 

framework • 234 
G 

garde* 167, 183 

generalisation • 50, 1 14, 122 
automate • 161 
d'etat • 171 

generation • 257, 285 
de code C++ • 381 
de code IDL • 397 



de code Java • 391 
de code SQL • 405 
de code Visual Basic • 401 

generique 

cadre methodologique • 199 
classe • 98 

collaboration, pattern • 149 
description d'association • 105 
instanciation de • 378 
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Contenu du CD-Rom 



Tous les efforts ont ete faits pour tester avec soin le CD-Rom et les programmes qu'il 
contient. Neanmoins, les Editions EYROLLES ne pourront etre tenues pour 
responsables des prejudices ou dommages de quelque nature que ce soit pouvant 
resulter de l'utilisation de ces programmes. 



